This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 10.4 needs to discuss how midnight (24:00:00) is handled. I believe the correct treatment is that when filling in values from the reference date time, the value 24:00:00 is considered to be the same as 00:00:00 on the following day. Thus if the reference date is 1972-12-31, the time 24:00:00 expands to 1973-01-01T00:00:00, with the consequence that 24:00:00 and 00:00:00 are not equal. But the dateTimes 2005-04-04T24:00:00 and 2005:04-05:00:00:00 *are* equal. Michael Kay
Please see a more extended discussion of the topic and a detailed proposal at http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Apr/0053.html (Member-only) Michael Kay
The WGS decided on 5-10-2005 to accept Mike Kay's proposal in http://lists.w3.org/Archives/Member/w3c-xsl-query/2005May/0004.html
Since the URL given was member-only here is the details of the adopted proposal: === So here are the changes we need to make for the alternative proposal, which makes it represent the start of the day when used as a time, but the end of the day when used in a dateTime. This mainly consists of examples to alert people to the possible surprises that this causes. In the data model, add a note to 3.3.2 that the lexical representation "24:00:00" maps to the value (0,0,0), while 1999-12-31T24:00:00 maps to the value (2000, 1, 1, 0, 0, 0). In F+O: Section 5.2. Add two examples: fn:dateTime(xs:date("1999-12-31"), xs:time("12:00:00")) => xs:dateTime("1999-12-31T12:00:00") fn:dateTime(xs:date("1999-12-31"), xs:time("24:00:00")) => xs:dateTime("1999-12-31T00:00:00") with perhaps a word of explanation. Section 10.1: explain in the text or by examples that the lexical representation "24:00:00" maps to the value (0,0,0), while 1999-12-31T24:00:00 maps to the value (2000, 1, 1, 0, 0, 0). In 10.4, to the paragraph starting "The starting instant of an occurrence of a date/time value is an xs:dateTime calculated by filling in the missing components..." add: "If the xs:time value written as 24:00:00 is to be compared, filling in the missing components gives 1972-12-31T00:00:00, because 24:00:00 is treated as being simply an alternative representation of 00:00:00 (the lexical value 24:00:00 is converted to the components (0,0,0) before the missing components are filled in). This has the consequence that when ordering xs:time values, 24:00:00 is considered to be earlier than 23:59:59. However, when ordering xs:dateTime values, a time of 24:00:00 is considered equivalent to 00:00:00 on the following day." Section 10.4.7.1: add the examples op:dateTime-equal(xs:dateTime("1999-12-31T24:00:00"), xs:dateTime("2000-01-01T00:00:00")) returns true op:dateTime-equal(xs:dateTime("2005-04-04T24:00:00"), xs:dateTime("2005-04-04T00:00:00")) returns false Section 10.4.13: add the example op:time-equal(xs:time("24:00:00+01:00"), xs:time("00:00:00+01:00")) returns true Section 10.4.14: add the example op:time-less-than(xs:time("23:59:59"), xs:time("24:00:00")) return false Section 10.5.7: add the example fn:year-from-dateTime(xs:dateTime("1999-12-31T24:00:00")) returns 2000 Section 10.5.10: add the example fn:hours-from-dateTime(xs:dateTime("1999-12-31T24:00:00")) returns 0 Section 10.5.18: add the example fn:hours-from-time(xs:time("24:00:00")) returns 0 Section 10.8.3: add the example op:subtract-times(xs:time("24:00:00"), xs:time("23:59:59")) returns xdt:dayTimeDuration("-PT23H59M59S"), with an explanation as with the other examples. Section 17.1.2, to the paragraph starting "If ST is xs:dateTime, xs:date or xs:time, ..." add "Note that the hours component of the resulting string will never be 24. Midnight is always represented as "00:00:00". ===