This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, In section 5.2.1 of the XQuery 1.0 and XPath 2.0 Functions and Operators specification [1], it says: > fn:dateTime(xs:date("1999-12-31"), xs:time("24:00:00")) returns > xs:dateTime("1999-12-31T00:00:00") because "24:00:00" is an alternate lexical > form for "00:00:00". However, to my understanding the ISO 8601 standard says that 00:00 is the beginning of a day, and 24:00 is the end of a day, quote [2]: > As every day both starts and ends with midnight, the two notations 00:00 and > 24:00 are available to distinguish the two midnights that can be associated > with one date. This means that the following two notations refer to exactly > the same point in time: > > 1995-02-04 24:00 = 1995-02-05 00:00 That is, xs:time should not lose information that is explicitly specified in the string it is being constructed from (being "24:00:00" instead of "00:00:00"). It should be stored internally as 24:00:00, and if it is combined with a date should either return "1999-12-31T24:00:00" or "2000-01-01T00:00:00". So, I would suggest the example in the specification to be changed to something like this: fn:dateTime(xs:date("1999-12-31"), xs:time("24:00:00")) returns xs:dateTime("2000-01-01T00:00:00") because "24:00:00" is an alternate lexical form for "00:00:00" on the next day. ~Grauw [1] http://www.w3.org/TR/xpath-functions/#func-dateTime-examples [2] http://www.cl.cam.ac.uk/~mgk25/iso-time.html
The example is not incorrect: it is there to illustrate a feature of the specification that users might find surprising. You're not asking us to change the example, you're asking us to change a design decision that was debated quite carefully. In the XML Schema xs:time data type, 00:00:00 and 24:00:00 are different lexical representations of the same underlying value. Therefore, they must behave the same way in all operations, including the operation of combining the value with a date to give a dateTime. We could have tried changing the value space to retain the difference, as we did with timezone information, but we're reluctant to do this as it would cause increasing divergence with the semantics of the data types as defined and used in XML Schema, for example the meaning of a value range applied as a constraint to xs:time values. Michael Kay (personal response: the comment will be considered more fully by the WGs)
The Working Groups discussed this comment at the recent face-to-face meeting and endorsed the response which I had previously given privately: the example is correct, and is there to alert the reader to a feature of the specification that users may find surprising. I am therefore closing the comment with the disposition "invalid" (meaning we think there is no error). But thank you for raising the comment, and if you do not agree to this closure, please reopen it stating your reasons. Michael Kay for the XSL and XQuery Working Groups