This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT approved comment In 3.3.8.4, fourth bullet, the reference to dayFrag should be to secondFrag. In 3.3.8.4, it is not made clear whether 2006-02-20T00:00:00 is equal to, or identical to, 2006-02-19T24:00:00. In 3.3.9.4, it is not made clear whether 00:00:00 is equal to, or identical to, 24:00:00 (and how this interacts with timezones).
(In reply to comment #0) > In 3.3.8.4, fourth bullet, the reference to dayFrag should be to secondFrag. Known typo. > In 3.3.8.4, it is not made clear whether 2006-02-20T00:00:00 is equal to, or > identical to, 2006-02-19T24:00:00. Agreed, we could be more explicit. A 7-property date/time value cannot have a minute property whose value is 24; the lexical representation '2006-02-19T24:00:00' is mapped to (2006,2,20,0,0,0,absent). (The 7th property, with value absent, is the time zone.) > In 3.3.9.4, it is not made clear whether 00:00:00 is equal to, or identical to, > 24:00:00 (and how this interacts with timezones). See above for equal/identical. For better or for worse, 24:00:00 is 00:00:00 and hence preceeds all other untimezoned times (or, with timezone attached, all other times in that timezone). That said, the values interact WRT equality the same as other values. Compute the two values for timeOnTimeline and compare the resulting numbers.
(In reply to comment #0) > QT approved comment > In 3.3.8.4, it is not made clear whether 2006-02-20T00:00:00 is equal to, or > identical to, 2006-02-19T24:00:00. > > In 3.3.9.4, it is not made clear whether 00:00:00 is equal to, or identical to, > 24:00:00 (and how this interacts with timezones). I believe that these two parts duplicate or are subsumed by 2497, which is still an open bug. Will consider them resolved/closed/etc. when 2497 is resolved/closed/etc. unless someone objects. (In reply to comment #1) > Agreed, we could be more explicit. A 7-property date/time value cannot have > a minute property whose value is 24; the lexical representation > '2006-02-19T24:00:00' is mapped to (2006,2,20,0,0,0,absent). But there is an error in the lexical mapping, see bug 2851.
(In reply to comment #2) > But there is an error in the lexical mapping, see bug 2851. Oops! Should be: see bug 3851
(In reply to comment #2) > I believe that these two parts duplicate or are subsumed by 2497, which is > still an open bug. Will consider them resolved/closed/etc. when 2497 is > resolved/closed/etc. unless someone objects. While the proposed decision for bug 2497 and the fix to bug 3851 will fix both of these two, technically bug 2947 is only about time, not both time and dateTime, so only the first of the two is a duplicate. Nonetheless, if 3851 is fixed as proposed, it will fix these two as well.
In 3.3.8.4, fourth bullet, the reference to dayFrag is changed to secondFrag. (The other problems related in 3258 will be corrected by 3851.)
Marked decided since 3851 is decided, and the typo was explicitly acknowledged. Not yet in status quo.
The change proposed above was approved by the WG in its call of 1 December 2006. It is now reflected in the status quo version of the Datatypes spec. Accordingly, I am setting the disposition of this issue to RESOLVED / FIXED. If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. To signal that the resolution is acceptable, change the status of the issue to CLOSED. Otherwise, to signal that it's NOT acceptable, change the status to REOPENED (and tell us what's wrong). If we don't hear from you in the next three weeks, we'll assume that silence betokens consent, and close the issue ourselves.