GNOME Bugzilla – Bug 323046
exslt date:add failure
Last modified: 2005-12-06 07:34:38 UTC
Please describe the problem: The following 2 expressions return nothing: <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT3S')" /> <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT123S')" /> seems like add cant "roll over" to exactly 00 seconds and it cant roll the hour at all. E.g. <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT4S')" /> returns "2005-12-01T16:58:01Z" But <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT124S')" /> returns nothing. Steps to reproduce: <?xml version="1.0" encoding="utf-8" standalone="yes" ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:date="http://exslt.org/dates-and-times" extension-element-prefixes="date" > <xsl:output method="xml" encoding="utf-8" indent="no" /> <xsl:template match="/"> <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT3S')" /> <xsl:value-of select="date:add('2005-12-01T16:57:57Z', 'PT123S')" /> </xsl:template> Actual results: I get the xml prolog:<?xml version="1.0" encoding="utf-8"?> and nothing else. Expected results: 2005-12-01T16:58:00Z 2005-12-01T17:00:00Z Does this happen every time? yes Other information: xsltproc -V Using libxml 20620, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20620, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20620 libexslt 812 was compiled against libxml 20620
$ xsltproc bug323046.xsl data.xml <?xml version="1.0" encoding="utf-8"?> 2005-12-01T16:58:00Z2005-12-01T17:00:00Z $ xsltproc -V Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20621, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20621 libexslt 812 was compiled against libxml 20621 Can you do your test again with newer versions of libxml2 ?
I have tried to reproduce this problem with libxml2-2.6.20 and libxslt-1.1.15, on both 32-bit and 64- bit versions, but it all woks correctly for me: bill@bbsf ~/gnomecvs/bug323046 $ ./xsltproc -V bug.xsl bug.xsl Using libxml 20620, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20620, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20620 libexslt 812 was compiled against libxml 20620 <?xml version="1.0" encoding="utf-8"?> 2005-12-01T16:58:00Z2005-12-01T17:00:00Z I also tried the script with current CVS, again with no problem found.
Verified that it still happens w/ libxml2 v. 2.6.22. That is, I only get the xml prolog back from the processor. Would you recommend getting the CVS head for exslt, libxslt, or libxml2? xsltproc -V: Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 FYI, I am using a Gentoo installation; uname -a: Linux (hostname) 2.6.7 #10 Wed Dec 15 15:08:26 CST 2004 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Thx for looking at this.
Created attachment 55656 [details] stylesheet for the report
The only thing which I can see wrong is that your stylesheet is missing the closing tag </xsl:stylesheet>. I am also using Gentoo systems, and there is no problem with this test on any of them: wbrack@mmm1 ~ $ uname -a Linux mmm1 2.6.12.5-05Sep05 #1 SMP Mon Sep 5 10:58:08 HKT 2005 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux wbrack@mmm1 ~ $ xsltproc -V bug323046.xsl bug323046.xsl Using libxml 20620, libxslt 10114 and libexslt 812 xsltproc was compiled against libxml 20619, libxslt 10114 and libexslt 812 libxslt 10114 was compiled against libxml 20619 libexslt 812 was compiled against libxml 20619 <?xml version="1.0" encoding="utf-8"?> 2005-12-01T16:58:00Z2005-12-01T17:00:00Z wbrack@bbsf ~ $ uname -a Linux bbsf 2.6.14-gentoo-r2-25Nov-mppe #3 SMP Fri Nov 25 18:35:01 PST 2005 x86_64 AMD Opteron(tm) Processor 248 AuthenticAMD GNU/Linux wbrack@bbsf ~ $ xsltproc -V bug323046.xsl bug323046.xsl Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20619, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20619 libexslt 812 was compiled against libxml 20619 <?xml version="1.0" encoding="utf-8"?> 2005-12-01T16:58:00Z2005-12-01T17:00:00Z I am attaching the complete stylesheet (including end tag) which I'm using for my tests. Please download it and execute the same command, then (if you still think there is a problem) paste your full console output to the bug report. The command is: xsltproc -V bug323046.xsl bug323046.xsl
> The only thing which I can see wrong is that your stylesheet is missing > the closing tag </xsl:stylesheet>. Yes, of course. I must have missed that line in the copy/paste. I ran your stylesheet and the xml prolog is the only result. I can create this on my work pc and home pc (also Gentoo). Home uname -a: Linux (hostname) 2.4.26-gentoo-r5 #6 SMP Mon Jul 12 10:52:25 CDT 2004 i686 Celeron (Mendocino) GenuineIntel GNU/Linux I will rebuild the libxml2 at home as well, but I suspect the behaviour will remain the same as it did here at work. ===begin=== Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 <?xml version="1.0" encoding="utf-8"?> ===end===
Does the date-time extensions rely on any libraries outside libexslt, libxslt, libxml2? Some external depenedcy I can look at?
Verified at home "feature" is still there using previously attached stylesheet: ===begin=== Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 <?xml version="1.0" encoding="utf-8"?> ===end=== This is on the home uname -a Gentoo box: Linux (hostname) 2.4.26-gentoo-r5 #6 SMP Mon Jul 12 10:52:25 CDT 2004 i686 Celeron (Mendocino) GenuineIntel GNU/Linux
Another note: I ran the add-duration.1.xml / add-duration.1.xsl test cases and came out w/ slightly different results. The diffs are: add-duration : P30D + PT24H result : P30DT24H (>instead of P31D) add-duration : P12M29D + P365D result : P1Y393DT24H (>instead of P1Y394D) add-duration : P1000Y11M30DT23H59M0.1S + PT59.9S result : P1000Y11M30DT24H (>instead of P1000Y11M31D) add-duration : P1000Y11M30DT23H59M1S + PT59S result : P1000Y11M30DT24H (>instead of P1000Y11M31D) Full results: add-duration : P1Y + -P1Y result : P0D add-duration : P1M + -P1M result : P0D add-duration : P1D + -P1D result : P0D add-duration : PT1H + -PT1H result : P0D add-duration : PT1M + -PT1M result : P0D add-duration : PT1S + -PT1S result : P0D add-duration : P1Y + -P12M result : P0D add-duration : P1D + -PT24H result : P0D add-duration : P1D + -PT1440M result : P0D add-duration : P1D + -PT86400S result : P0D add-duration : P1Y1D + -P12MT86400S result : P0D add-duration : P30D + PT24H result : P30DT24H add-duration : P10Y + P45M result : P13Y9M add-duration : P10Y + -P12M result : P9Y add-duration : P5Y11M + -P12M result : P4Y11M add-duration : P1000Y11M30D + -PT9S result : P1000Y11M29DT23H59M51S add-duration : P12M29D + P365D result : P1Y393DT24H add-duration : P1000Y + PT45.65S result : P1000YT45.65S add-duration : PT23H59M0S + PT59S result : PT23H59M59S add-duration : PT23H59M0S + PT61S result : P1DT1S add-duration : P1000Y11M30DT23H59M0.1S + PT59.9S result : P1000Y11M30DT24H add-duration : P1000Y11M30DT23H59M1S + PT59S result : P1000Y11M30DT24H add-duration : P1000Y11M30D + -P1DT9S result : P1000Y11M28DT23H59M51S Could this be timezone related? My /etc/localtime: lrwxrwxrwx 1 root root 27 Jul 12 2004 localtime -> /usr/share/zoneinfo/CST6CDT (all files standard to Gentoo distribution)
I also just ran testcase add.1.xsl and got the following (parenthesis are mine): add : 2000-01-01T01:01:00Z + PT0S result : 2000-01-01T01:01:00Z add : 2000-01-01T01:01:00Z + PT60S result : (> empty string instead of 2000-01-01T01:02:00Z) add : 2000-01-01T01:01:00Z + PT59S result : 2000-01-01T01:01:59Z add : 2000-01-01 + PT86400S result : (> empty string instead of 2000-01-02) add : 2000-02-29 + PT86400S result : (> empty string instead of 2000-03-01) add : 2000-01-01 + -PT86400S result : 1999-12-31 add : -0001-12-31T23:59:59 + PT1S result : (> empty string instead of 0001-01-01T00:00:00Z) add : 0001-01-01T00:00:00 + -PT1S result : -0001-12-31T23:59:59Z add : 2000-01-01T00:00:00Z + -PT59S result : 1999-12-31T23:59:01Z add : -0001 + -PT59S result : -0002-12-31T23:59:01Z add : -0001 + P1Y result : 0001-02 (> instead of 0001) add : 2000-01 + -PT86400S result : 1999-12-31 add : 2000-01 + -P1D result : 1999-12-31 add : 1970-01-01T00:00:00-00:30 + -PT30S result : 1970-01-01T00:29:30Z I will keep trying further tests ...
Created attachment 55663 [details] Results of my run of the testcases Gziped results of my run of the testcases. Note: there are a few more deviations than those already posted. All testcases ran @ home w/ -V: Using libxml 20622, libxslt 10115 and libexslt 812 xsltproc was compiled against libxml 20622, libxslt 10115 and libexslt 812 libxslt 10115 was compiled against libxml 20622 libexslt 812 was compiled against libxml 20622 And uname -a: Linux (hostname) 2.4.26-gentoo-r5 #6 SMP Mon Jul 12 10:52:25 CDT 2004 i686 Celeron (Mendocino) GenuineIntel GNU/Linux Q: is any os/c/c++ runtime libraries called? Something that 2.4.26 (home) or 2.6.7 (work) might be doing wrong?
You can see the libraries which are called upon by ldd /usr/bin/xsltproc and you can see what's being done by date:add by reading the code in libxslt/libexslt/date.c. Basically, most of the work is done by libm (for round and ceil) which (on Gentoo) is a part of sys-libs/glibc. At this time it appears that your problem is something which is unique to your systems. I have run your test on six other systems around the world, and on each of them there is no apparent problem. Another reporter (Bart Martens, whose comments are above) has also confirmed that it is working for him. The only other thing I can think of which might have some adverse effects would be "overly-aggressive" CFLAGS in Gentoo's make.conf. That could affect both libxml2/libxslt and glibc compilations. However, that seems to me to be quite unlikely. Since I am convinced this is not an inherent bug within the libxml2/libxslt libraries, I am going to close this bug report as NOTABUG. If you wish to pursue the matter further, you are welcome to contact me by direct email.
Created attachment 55667 [details] Simpler CFLAGS ... Update: some improvement. I have pretty aggressive compiler flags turned on in my make.conf: CFLAGS="-O3 -pipe -march=pentium2 -mmmx -ffast-math -mfpmath=387 -fomit-frame-pointer -fforce-addr -falign-functions=4" I reduced these to: CFLAGS="-O -pipe" And I get the attachment. Not a successful test ... but no empty strings. I will add flags 1 by 1 to see who causes the empty string from 'date:add' (I suspect 1 of the last 5). Maybe an 'assert' can be added to pin point the error in future releases (I'll keep testing). I have used these flags w/o "features" in the kernel, compilers, X Windows, bzip2, gzip, (x|gnu)emacs, etc... I thought it was safe b/c some of these packages *must* use floating point operations (graphics, coordinates, compression, etc...) and the stack stuff never interfered; but I guess it affects date-time calculations ... it _must_ affect date-time calculations. BUT, are the still erroneous test results due to these same flags in the kernel/c-runtime?
Created attachment 55674 [details] stylesheet to create "00" in second, minute, and hour output next
Created attachment 55675 [details] output of good/bad fast-math tests True ... NOTABUG; except I still get deviations in the "week-in-year" tests (as earlier attached). But I expect I need a kernel/library recompile to explore that. If I include all my existing flags except "-ffast-math", the date:add feature goes away. An additional test case including that flag might prove useful. In all failing cases, if the second, minute, or hour fields are "00"; the empty string is returned. I do not know if day, month, or year are affected (I will test that). The "-ffast-math" excludes "div by 0" detection (IIRC) and that seems to hold true w/ this errata. If I force a the second or minute or hour to "roll" (see attached stylesheet and output) the output is ok (even under fast-math). If I date:add to be second or minute or hour to be "00"; it fails. It sounds like a latent "feature" to the math co-processor routines. Which maybe should be "assert"-ed?? Thx for bearing w/ me! And please consider these last 2 attachments as a test case. -- Rodman
Last comment (promise), Y-M-D do NOT seem to be affected ... since none of them equal zero (at least in recent history). So testing fast-math + (00 == hour| minute|second) works. Thx again ... Rodman