Quantcast

FW: "FORG0001: Invalid dateTime value" on valid dateTime

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FW: "FORG0001: Invalid dateTime value" on valid dateTime

Cary Millsap
Um, the “good stuff” in my original note was truncated somehow en route to
the list. Maybe it will make it this time (below) in a plain-text resend.


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba

Visit www.hotsos.com for curriculum and schedule details...

________________________________________
From: Cary Millsap [mailto:[hidden email]]
Sent: Wednesday, September 21, 2005 10:23 AM
To: Saxon List ([hidden email])
Subject: "FORG0001: Invalid dateTime value" on valid dateTime

I’m getting unexpected behavior with xs:dateTime($t) when using microsecond
resolution in $t. When $t has a microsecond portion that’s less than
.999499, the last three digits are elided from the return value. When $t has
a microsecond portion that’s greater than .999499, the transformation fails
with a run-time error. I’m hoping this is a bug in either Java or Saxon
since http://www.w3.org/TR/xmlschema-2/#dateTime appears to permit 6-digit
precision in the fractional seconds portion of an xs:dateTime. ?

I’m of course hoping not to have to work around this, but if I do, I’ll have
to figure out how to compute the semantic equivalent of $elapsed = $t1 –
$t0, where each of the three operands requires microsecond precision.

Please see the test case below.


$ "%P5_JAVA%" -version
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

$ "%P5_JAVA%" -jar "%P5_SAXON%" -?
Saxon 8.5 from Saxonica
Usage: java net.sf.saxon.Transform [options] source-doc style-doc
{param=value}...
...

$ cat bug.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
       <xsl:template match="task">
              <xsl:element name="test">
                     <xsl:attribute name="t1" select="xs:dateTime(@t1)"/>
              </xsl:element>
       </xsl:template>
</xsl:stylesheet>


$ cat good.xml
<?xml version="1.0" encoding="UTF-8"?>
<task t1="2003-11-27T07:55:16.999499Z"/>

$ "%P5_JAVA%" -jar "%P5_SAXON%" good.xml bug.xsl
<?xml version="1.0" encoding="UTF-8"?><test t1="2003-11-27T07:55:16.999Z"/>


$ cat bad.xml
<?xml version="1.0" encoding="UTF-8"?>
<task t1="2003-11-27T07:55:16.999500Z"/>

$ "%P5_JAVA%" -jar "%P5_SAXON%" bad.xml bug.xsl
Error on line 8 of
file:/C:/Documents%20and%20Settings/Cary%20Millsap/My%20Documents/Developmen
t/P5/testing/tests/xsl
  FORG0001: Invalid dateTime value. Non-existent date
Transformation failed: Run-time errors were reported


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba

Visit www.hotsos.com for curriculum and schedule details...





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: "FORG0001: Invalid dateTime value" on valid dateTime

Michael Kay
Java only maintains dates/times to millisecond precision. Saxon is therefore
rounding the supplied date/time to the nearest millisecond, and it appears
it is getting the rounding wrong if the seconds are of the form xx.999500,
i.e. where the rounding would increase the number of integer seconds.

In the next release Saxon will support dates/times to microsecond precision
- to achieve this I am reducing the amount of dependence on the Java
date/time classes.

In fact, the XSLT/XQuery F+O specification only requires millisecond
precision, but since I have to support the semantics of date/time comparison
for schema validation as well, and that requires microseconds, I thought I
might as well take the plunge and do it.

You could do a quick-and-dirty fix to prevent the failure by adding after
line 177 of DateTimeValue.java

      millisecond = (int)(Math.round(fractionalSeconds * 1000));
      if (millisecond > 999) millisecond = 999;

but of course to do it properly one should really carry into the seconds and
exceptionally the minutes, hours, etc.

Hope you can live with this until next release.

(Would it be useful to get you a prerelease of this? I'm aware that
reimplementing the date/time arithmetic might well introduce bugs despite
best efforts at testing, so if you've got code that relies on date/time
arithmetic it would be nice to use it as an extra test case.)

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: Cary Millsap [mailto:[hidden email]]
> Sent: 21 September 2005 16:41
> To: Saxon List
> Subject: FW: "FORG0001: Invalid dateTime value" on valid dateTime
>
> Um, the “good stuff” in my original note was truncated
> somehow en route to
> the list. Maybe it will make it this time (below) in a
> plain-text resend.
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
> ________________________________________
> From: Cary Millsap [mailto:[hidden email]]
> Sent: Wednesday, September 21, 2005 10:23 AM
> To: Saxon List ([hidden email])
> Subject: "FORG0001: Invalid dateTime value" on valid dateTime
>
> I’m getting unexpected behavior with xs:dateTime($t) when
> using microsecond
> resolution in $t. When $t has a microsecond portion that’s less than
> .999499, the last three digits are elided from the return
> value. When $t has
> a microsecond portion that’s greater than .999499, the
> transformation fails
> with a run-time error. I’m hoping this is a bug in either
> Java or Saxon
> since http://www.w3.org/TR/xmlschema-2/#dateTime appears to
> permit 6-digit
> precision in the fractional seconds portion of an xs:dateTime. ?
>
> I’m of course hoping not to have to work around this, but if
> I do, I’ll have
> to figure out how to compute the semantic equivalent of
> $elapsed = $t1 –
> $t0, where each of the three operands requires microsecond precision.
>
> Please see the test case below.
>
>
> $ "%P5_JAVA%" -version
> java version "1.5.0_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" -?
> Saxon 8.5 from Saxonica
> Usage: java net.sf.saxon.Transform [options] source-doc style-doc
> {param=value}...
> ...
>
> $ cat bug.xsl
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet version="2.0"
>        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>        xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >
>        <xsl:template match="task">
>               <xsl:element name="test">
>                      <xsl:attribute name="t1"
> select="xs:dateTime(@t1)"/>
>               </xsl:element>
>        </xsl:template>
> </xsl:stylesheet>
>
>
> $ cat good.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <task t1="2003-11-27T07:55:16.999499Z"/>
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" good.xml bug.xsl
> <?xml version="1.0" encoding="UTF-8"?><test
> t1="2003-11-27T07:55:16.999Z"/>
>
>
> $ cat bad.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <task t1="2003-11-27T07:55:16.999500Z"/>
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" bad.xml bug.xsl
> Error on line 8 of
> file:/C:/Documents%20and%20Settings/Cary%20Millsap/My%20Docume
> nts/Developmen
> t/P5/testing/tests/xsl
>   FORG0001: Invalid dateTime value. Non-existent date
> Transformation failed: Run-time errors were reported
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
>
>
>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: "FORG0001: Invalid dateTime value" on valid dateTime

Cary Millsap
Thank you Mike. I think a prerelease will be a great benefit to us.

I will be happy to supply some tests. As you're aware, our real application
has a lot of code and big, complex XML input data. But our reliance upon
xs:dateTime arithmetic boils down to one expression. Is there a single-file
test.xsl harness that you would prefer for me to use?


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba

Visit www.hotsos.com for curriculum and schedule details...

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Kay
Sent: Friday, September 23, 2005 3:29 AM
To: Cary Millsap; 'Saxon List'
Subject: [saxon] RE: "FORG0001: Invalid dateTime value" on valid dateTime

Java only maintains dates/times to millisecond precision. Saxon is therefore
rounding the supplied date/time to the nearest millisecond, and it appears
it is getting the rounding wrong if the seconds are of the form xx.999500,
i.e. where the rounding would increase the number of integer seconds.

In the next release Saxon will support dates/times to microsecond precision
- to achieve this I am reducing the amount of dependence on the Java
date/time classes.

In fact, the XSLT/XQuery F+O specification only requires millisecond
precision, but since I have to support the semantics of date/time comparison
for schema validation as well, and that requires microseconds, I thought I
might as well take the plunge and do it.

You could do a quick-and-dirty fix to prevent the failure by adding after
line 177 of DateTimeValue.java

      millisecond = (int)(Math.round(fractionalSeconds * 1000));
      if (millisecond > 999) millisecond = 999;

but of course to do it properly one should really carry into the seconds and
exceptionally the minutes, hours, etc.

Hope you can live with this until next release.

(Would it be useful to get you a prerelease of this? I'm aware that
reimplementing the date/time arithmetic might well introduce bugs despite
best efforts at testing, so if you've got code that relies on date/time
arithmetic it would be nice to use it as an extra test case.)

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: Cary Millsap [mailto:[hidden email]]
> Sent: 21 September 2005 16:41
> To: Saxon List
> Subject: FW: "FORG0001: Invalid dateTime value" on valid dateTime
>
> Um, the “good stuff” in my original note was truncated
> somehow en route to
> the list. Maybe it will make it this time (below) in a
> plain-text resend.
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
> ________________________________________
> From: Cary Millsap [mailto:[hidden email]]
> Sent: Wednesday, September 21, 2005 10:23 AM
> To: Saxon List ([hidden email])
> Subject: "FORG0001: Invalid dateTime value" on valid dateTime
>
> I’m getting unexpected behavior with xs:dateTime($t) when
> using microsecond
> resolution in $t. When $t has a microsecond portion that’s less than
> .999499, the last three digits are elided from the return
> value. When $t has
> a microsecond portion that’s greater than .999499, the
> transformation fails
> with a run-time error. I’m hoping this is a bug in either
> Java or Saxon
> since http://www.w3.org/TR/xmlschema-2/#dateTime appears to
> permit 6-digit
> precision in the fractional seconds portion of an xs:dateTime. ?
>
> I’m of course hoping not to have to work around this, but if
> I do, I’ll have
> to figure out how to compute the semantic equivalent of
> $elapsed = $t1 –
> $t0, where each of the three operands requires microsecond precision.
>
> Please see the test case below.
>
>
> $ "%P5_JAVA%" -version
> java version "1.5.0_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" -?
> Saxon 8.5 from Saxonica
> Usage: java net.sf.saxon.Transform [options] source-doc style-doc
> {param=value}...
> ...
>
> $ cat bug.xsl
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet version="2.0"
>        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>        xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >
>        <xsl:template match="task">
>               <xsl:element name="test">
>                      <xsl:attribute name="t1"
> select="xs:dateTime(@t1)"/>
>               </xsl:element>
>        </xsl:template>
> </xsl:stylesheet>
>
>
> $ cat good.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <task t1="2003-11-27T07:55:16.999499Z"/>
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" good.xml bug.xsl
> <?xml version="1.0" encoding="UTF-8"?><test
> t1="2003-11-27T07:55:16.999Z"/>
>
>
> $ cat bad.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <task t1="2003-11-27T07:55:16.999500Z"/>
>
> $ "%P5_JAVA%" -jar "%P5_SAXON%" bad.xml bug.xsl
> Error on line 8 of
> file:/C:/Documents%20and%20Settings/Cary%20Millsap/My%20Docume
> nts/Developmen
> t/P5/testing/tests/xsl
>   FORG0001: Invalid dateTime value. Non-existent date
> Transformation failed: Run-time errors were reported
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
>
>
>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: "FORG0001: Invalid dateTime value" on valid dateTime

Michael Kay
If you can supply some cut-down test material that exercises the cases you
consider important, that will be very useful.

Mike

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Cary Millsap
> Sent: 23 September 2005 19:13
> To: [hidden email]
> Subject: RE: [saxon] RE: "FORG0001: Invalid dateTime value"
> on valid dateTime
>
> Thank you Mike. I think a prerelease will be a great benefit to us.
>
> I will be happy to supply some tests. As you're aware, our
> real application
> has a lot of code and big, complex XML input data. But our
> reliance upon
> xs:dateTime arithmetic boils down to one expression. Is there
> a single-file
> test.xsl harness that you would prefer for me to use?
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Michael Kay
> Sent: Friday, September 23, 2005 3:29 AM
> To: Cary Millsap; 'Saxon List'
> Subject: [saxon] RE: "FORG0001: Invalid dateTime value" on
> valid dateTime
>
> Java only maintains dates/times to millisecond precision.
> Saxon is therefore
> rounding the supplied date/time to the nearest millisecond,
> and it appears
> it is getting the rounding wrong if the seconds are of the
> form xx.999500,
> i.e. where the rounding would increase the number of integer seconds.
>
> In the next release Saxon will support dates/times to
> microsecond precision
> - to achieve this I am reducing the amount of dependence on the Java
> date/time classes.
>
> In fact, the XSLT/XQuery F+O specification only requires millisecond
> precision, but since I have to support the semantics of
> date/time comparison
> for schema validation as well, and that requires
> microseconds, I thought I
> might as well take the plunge and do it.
>
> You could do a quick-and-dirty fix to prevent the failure by
> adding after
> line 177 of DateTimeValue.java
>
>       millisecond = (int)(Math.round(fractionalSeconds * 1000));
>       if (millisecond > 999) millisecond = 999;
>
> but of course to do it properly one should really carry into
> the seconds and
> exceptionally the minutes, hours, etc.
>
> Hope you can live with this until next release.
>
> (Would it be useful to get you a prerelease of this? I'm aware that
> reimplementing the date/time arithmetic might well introduce
> bugs despite
> best efforts at testing, so if you've got code that relies on
> date/time
> arithmetic it would be nice to use it as an extra test case.)
>
> Michael Kay
> http://www.saxonica.com/
>
>
> > -----Original Message-----
> > From: Cary Millsap [mailto:[hidden email]]
> > Sent: 21 September 2005 16:41
> > To: Saxon List
> > Subject: FW: "FORG0001: Invalid dateTime value" on valid dateTime
> >
> > Um, the “good stuff” in my original note was truncated
> > somehow en route to
> > the list. Maybe it will make it this time (below) in a
> > plain-text resend.
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > Nullius in verba
> >
> > Visit www.hotsos.com for curriculum and schedule details...
> >
> > ________________________________________
> > From: Cary Millsap [mailto:[hidden email]]
> > Sent: Wednesday, September 21, 2005 10:23 AM
> > To: Saxon List ([hidden email])
> > Subject: "FORG0001: Invalid dateTime value" on valid dateTime
> >
> > I’m getting unexpected behavior with xs:dateTime($t) when
> > using microsecond
> > resolution in $t. When $t has a microsecond portion that’s less than
> > .999499, the last three digits are elided from the return
> > value. When $t has
> > a microsecond portion that’s greater than .999499, the
> > transformation fails
> > with a run-time error. I’m hoping this is a bug in either
> > Java or Saxon
> > since http://www.w3.org/TR/xmlschema-2/#dateTime appears to
> > permit 6-digit
> > precision in the fractional seconds portion of an xs:dateTime. ?
> >
> > I’m of course hoping not to have to work around this, but if
> > I do, I’ll have
> > to figure out how to compute the semantic equivalent of
> > $elapsed = $t1 –
> > $t0, where each of the three operands requires microsecond
> precision.
> >
> > Please see the test case below.
> >
> >
> > $ "%P5_JAVA%" -version
> > java version "1.5.0_04"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> 1.5.0_04-b05)
> > Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" -?
> > Saxon 8.5 from Saxonica
> > Usage: java net.sf.saxon.Transform [options] source-doc style-doc
> > {param=value}...
> > ...
> >
> > $ cat bug.xsl
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsl:stylesheet version="2.0"
> >        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >        xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > >
> >        <xsl:template match="task">
> >               <xsl:element name="test">
> >                      <xsl:attribute name="t1"
> > select="xs:dateTime(@t1)"/>
> >               </xsl:element>
> >        </xsl:template>
> > </xsl:stylesheet>
> >
> >
> > $ cat good.xml
> > <?xml version="1.0" encoding="UTF-8"?>
> > <task t1="2003-11-27T07:55:16.999499Z"/>
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" good.xml bug.xsl
> > <?xml version="1.0" encoding="UTF-8"?><test
> > t1="2003-11-27T07:55:16.999Z"/>
> >
> >
> > $ cat bad.xml
> > <?xml version="1.0" encoding="UTF-8"?>
> > <task t1="2003-11-27T07:55:16.999500Z"/>
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" bad.xml bug.xsl
> > Error on line 8 of
> > file:/C:/Documents%20and%20Settings/Cary%20Millsap/My%20Docume
> > nts/Developmen
> > t/P5/testing/tests/xsl
> >   FORG0001: Invalid dateTime value. Non-existent date
> > Transformation failed: Run-time errors were reported
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > Nullius in verba
> >
> > Visit www.hotsos.com for curriculum and schedule details...
> >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RE: "FORG0001: Invalid dateTime value" on valid dateTime

Cary Millsap
Mike,

Here is a quick test case that you might find useful. Thank you very much!


test.xsl
--------
<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="2.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<!--
To run this test, use:
$ java -jar "%SAXON%" whatever.xml test.xsl FAIL=0  // to let it run
$ java -jar "%SAXON%" whatever.xml test.xsl         // to crash 8.5.1
-->

<xsl:param name="FAIL" as="xs:boolean" select="true()"/>
<xsl:variable name="s-good" select="'2005-09-23T07:00:00.999499'"/>
<xsl:variable name="s-bad"  select="'2005-09-23T07:00:00.999501'"/>

<xsl:template match="/">
The following reference crashes Saxon 8.5.1:
<xsl:if test="$FAIL">
<xsl:value-of select="xs:dateTime($s-bad)"/>
</xsl:if>
The following reference doesn't crash Saxon 8.5.1, but notice the loss of
precision on the value:
expected  2005-09-23T07:00:00.999499
actual    <xsl:value-of select="xs:dateTime($s-good)"/>

<xsl:variable name="FORMAT-DATETIME">[h]:[m01]:[s01].[f000001] [P] [D] [MNn]
[Y1{4}] [FNn]</xsl:variable>

The following quantity renders with only three fractional digits of
precision in Saxon 8.5.1:
expected   7:00:00.999499 a.m. 23 September 2005 Friday
actual     <xsl:value-of
select="format-dateTime(xs:dateTime($s-good),$FORMAT-DATETIME)"/>
</xsl:template>
</xsl:transform>



Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Nullius in verba

Visit www.hotsos.com for curriculum and schedule details...


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Kay
Sent: Friday, September 23, 2005 1:34 PM
To: [hidden email]
Subject: RE: [saxon] RE: "FORG0001: Invalid dateTime value" on valid
dateTime

If you can supply some cut-down test material that exercises the cases you
consider important, that will be very useful.

Mike

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Cary Millsap
> Sent: 23 September 2005 19:13
> To: [hidden email]
> Subject: RE: [saxon] RE: "FORG0001: Invalid dateTime value"
> on valid dateTime
>
> Thank you Mike. I think a prerelease will be a great benefit to us.
>
> I will be happy to supply some tests. As you're aware, our
> real application
> has a lot of code and big, complex XML input data. But our
> reliance upon
> xs:dateTime arithmetic boils down to one expression. Is there
> a single-file
> test.xsl harness that you would prefer for me to use?
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> Nullius in verba
>
> Visit www.hotsos.com for curriculum and schedule details...
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Michael Kay
> Sent: Friday, September 23, 2005 3:29 AM
> To: Cary Millsap; 'Saxon List'
> Subject: [saxon] RE: "FORG0001: Invalid dateTime value" on
> valid dateTime
>
> Java only maintains dates/times to millisecond precision.
> Saxon is therefore
> rounding the supplied date/time to the nearest millisecond,
> and it appears
> it is getting the rounding wrong if the seconds are of the
> form xx.999500,
> i.e. where the rounding would increase the number of integer seconds.
>
> In the next release Saxon will support dates/times to
> microsecond precision
> - to achieve this I am reducing the amount of dependence on the Java
> date/time classes.
>
> In fact, the XSLT/XQuery F+O specification only requires millisecond
> precision, but since I have to support the semantics of
> date/time comparison
> for schema validation as well, and that requires
> microseconds, I thought I
> might as well take the plunge and do it.
>
> You could do a quick-and-dirty fix to prevent the failure by
> adding after
> line 177 of DateTimeValue.java
>
>       millisecond = (int)(Math.round(fractionalSeconds * 1000));
>       if (millisecond > 999) millisecond = 999;
>
> but of course to do it properly one should really carry into
> the seconds and
> exceptionally the minutes, hours, etc.
>
> Hope you can live with this until next release.
>
> (Would it be useful to get you a prerelease of this? I'm aware that
> reimplementing the date/time arithmetic might well introduce
> bugs despite
> best efforts at testing, so if you've got code that relies on
> date/time
> arithmetic it would be nice to use it as an extra test case.)
>
> Michael Kay
> http://www.saxonica.com/
>
>
> > -----Original Message-----
> > From: Cary Millsap [mailto:[hidden email]]
> > Sent: 21 September 2005 16:41
> > To: Saxon List
> > Subject: FW: "FORG0001: Invalid dateTime value" on valid dateTime
> >
> > Um, the “good stuff” in my original note was truncated
> > somehow en route to
> > the list. Maybe it will make it this time (below) in a
> > plain-text resend.
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > Nullius in verba
> >
> > Visit www.hotsos.com for curriculum and schedule details...
> >
> > ________________________________________
> > From: Cary Millsap [mailto:[hidden email]]
> > Sent: Wednesday, September 21, 2005 10:23 AM
> > To: Saxon List ([hidden email])
> > Subject: "FORG0001: Invalid dateTime value" on valid dateTime
> >
> > I’m getting unexpected behavior with xs:dateTime($t) when
> > using microsecond
> > resolution in $t. When $t has a microsecond portion that’s less than
> > .999499, the last three digits are elided from the return
> > value. When $t has
> > a microsecond portion that’s greater than .999499, the
> > transformation fails
> > with a run-time error. I’m hoping this is a bug in either
> > Java or Saxon
> > since http://www.w3.org/TR/xmlschema-2/#dateTime appears to
> > permit 6-digit
> > precision in the fractional seconds portion of an xs:dateTime. ?
> >
> > I’m of course hoping not to have to work around this, but if
> > I do, I’ll have
> > to figure out how to compute the semantic equivalent of
> > $elapsed = $t1 –
> > $t0, where each of the three operands requires microsecond
> precision.
> >
> > Please see the test case below.
> >
> >
> > $ "%P5_JAVA%" -version
> > java version "1.5.0_04"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> 1.5.0_04-b05)
> > Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" -?
> > Saxon 8.5 from Saxonica
> > Usage: java net.sf.saxon.Transform [options] source-doc style-doc
> > {param=value}...
> > ...
> >
> > $ cat bug.xsl
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsl:stylesheet version="2.0"
> >        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> >        xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > >
> >        <xsl:template match="task">
> >               <xsl:element name="test">
> >                      <xsl:attribute name="t1"
> > select="xs:dateTime(@t1)"/>
> >               </xsl:element>
> >        </xsl:template>
> > </xsl:stylesheet>
> >
> >
> > $ cat good.xml
> > <?xml version="1.0" encoding="UTF-8"?>
> > <task t1="2003-11-27T07:55:16.999499Z"/>
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" good.xml bug.xsl
> > <?xml version="1.0" encoding="UTF-8"?><test
> > t1="2003-11-27T07:55:16.999Z"/>
> >
> >
> > $ cat bad.xml
> > <?xml version="1.0" encoding="UTF-8"?>
> > <task t1="2003-11-27T07:55:16.999500Z"/>
> >
> > $ "%P5_JAVA%" -jar "%P5_SAXON%" bad.xml bug.xsl
> > Error on line 8 of
> > file:/C:/Documents%20and%20Settings/Cary%20Millsap/My%20Docume
> > nts/Developmen
> > t/P5/testing/tests/xsl
> >   FORG0001: Invalid dateTime value. Non-existent date
> > Transformation failed: Run-time errors were reported
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > Nullius in verba
> >
> > Visit www.hotsos.com for curriculum and schedule details...
> >
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> saxon-help mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help
>




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Loading...