Project

Profile

Help

Bug #2651

closed

select="xs:string(xs:dateTime('9999-12-31T23:59:59.9999999'))" gives => '9999-12-31T23:59:59.:"

Added by stewart menday about 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
XPath conformance
Sprint/Milestone:
Start date:
2016-02-26
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.6, 9.7
Fix Committed on Branch:
9.6, 9.7
Fixed in Maintenance Release:
Platforms:

Description

Running the following xslq;

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs">

<xsl:output method="xml" encoding="UTF-8" byte-order-mark="no" indent="yes"/>

<xsl:template match="/">

<xsl:sequence select="xs:string(xs:dateTime('9999-12-31T23:59:59.9999999'))"/>

</xsl:template>

</xsl:stylesheet>

Results in;

9999-12-31T23:59:59.:

Notice the : at the end of the string

If we remove the last 9 from the datetime or change it to a value below 9 results in the following;

9999-12-31T23:59:59.999999

Cheers

Stew

Actions #1

Updated by Michael Kay about 6 years ago

  • Category set to XPath conformance
  • Assignee set to Debbie Lockett

I have added this to the QT3 test suite as CastExpr/CastAs676

Actions #2

Updated by Debbie Lockett about 6 years ago

  • Fix Committed on Branch 9.6, 9.7 added

Bug fix committed on 9.6 and 9.7 branches.

Fix in DateTimeValue.makeDateTimeValue: if the microseconds value rounds to the upper bound of 1,000,000, then truncate to 999,999.

(So in QT3 test CastExpr/CastAs676 we now return 9999-12-31T23:59:59.999999)

Actions #3

Updated by Debbie Lockett about 6 years ago

  • Status changed from New to Resolved
Actions #4

Updated by stewart menday about 6 years ago

Why is there a limit of 6 digits in the factional part of a second? I thought that the W3 standard was for any number of digits?

The max DateTime value in dot net is 9999-12-31T23:59:59.9999999 (a precision of 100 nanoseconds), if you truncate this to 9999-12-31T23:59:59.999999 (a precision of 1 microsecond) you cannot test for value == DateTime.max.

Actions #5

Updated by Michael Kay about 6 years ago

The W3C specs require support for millisecond precision (3 fractional digits) in xs:dateTime (See Functions and Operators section 9.1.1). Saxon chooses to support microsecond precision (6 digits). I've no particular recollection about why this figure was chosen.

As far as I can see, there's nothing in the specs that says what you should do if casting from a string with more digits than this, but analogy with other data types suggests that rounding is a reasonable strategy. However, when we thought about your edge case, we decided that rounding the milliseconds in such a way that the date changes would not be what users wanted; if they are using a value like this, they almost certainly intend it to mean "the last representable point in time before the next day starts", so truncation is more appropriate. The alternative strategy, of rounding to 10000-01-01T00:00:00 would also create a value that's not equal to .NET's DateTime.max.

Actions #6

Updated by stewart menday about 6 years ago

Michael

Thanks for you prompt response, the level of support here is second to none, awesome job.

I agree with your reasoning here with regard to truncating as apposed to rounding but given that the native DateTime in dot net uses 100 nanosecond or 7 digit precision it would be best if the dot net (or all) version(s) of Saxon used 7 digits for DateTime values.

Actions #7

Updated by O'Neil Delpratt about 6 years ago

  • Applies to branch 9.7 added
Actions #8

Updated by O'Neil Delpratt about 6 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.4 added

Bug fix applied in the Saxon 9.7.0.4 maintenance release. Leave open until patched applied in the 9.6 maintenance release.

Actions #9

Updated by O'Neil Delpratt almost 6 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.6.0.9 added
  • Fixed in Maintenance Release deleted (9.7.0.4)

Bug fix applied in the Saxon 9.6.0.9 maintenance release.

Actions #10

Updated by O'Neil Delpratt almost 6 years ago

  • Sprint/Milestone set to 9.7.0.4
  • Fixed in Maintenance Release 9.7.0.4 added

Please register to edit this issue

Also available in: Atom PDF