This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In "3.3.9 time": "Note: The relative order of two time values, one of which has a ·timezoneOffset· of absent is determined by imputing time zone offsets of both +14:00 and −14:00 to the value without an offset. Many such combinations will be ·incomparable· because the two imputed time zone offsets yield different orders. However, for a given untimezoned value, there will always be timezoned values at one or both ends of the 52-hour interval that are ·comparable· (because the interval of ·incomparability· is only 24 hours wide)." Consider the untimezoned time value "12:00:00". What timezoned value(s) can be comparable? It's not clear how the 52-hour interval is relevant (it's for a calendar day, not a time value) and why the incomparable range is 24 hours wide (I would think 28).
(In reply to comment #0) > In "3.3.9 time": > Consider the untimezoned time value "12:00:00". What timezoned value(s) can be > comparable? E.g., 23:59:59-14:00 > 12:00:00-14:00:00 > 12:00:00+14:00, so 23:59:59-14:00 > 12:00:00 . > It's not clear how the 52-hour interval is relevant (it's for a > calendar day, not a time value) Well, from 00:00:00+14:00 to 23:59:59.99...-14:00 is almost (how many nines did you fill in?) 52 hours. > and why the incomparable range is 24 hours wide > (I would think 28). You may be right on this one. I'll have to chew on it for a while.
(In reply to comment #1) > (In reply to comment #0) > > and why the incomparable range is 24 hours wide > > (I would think 28). > > You may be right on this one. I'll have to chew on it for a while. I have chewed; I do believe you are right. I hope someone else will check it as well. Probably this same figure is wrong in comparable places elsewhere.
(In reply to comment #1) > (In reply to comment #0) > > In "3.3.9 time": > > > Consider the untimezoned time value "12:00:00". What timezoned value(s) can be > > comparable? > > E.g., 23:59:59-14:00 > 12:00:00-14:00:00 > 12:00:00+14:00, so 23:59:59-14:00 > > 12:00:00 . > > > It's not clear how the 52-hour interval is relevant (it's for a > > calendar day, not a time value) > > Well, from 00:00:00+14:00 to 23:59:59.99...-14:00 is almost (how many nines did > you fill in?) 52 hours. Further explanation: A time value does repeat each day, but comparing two time values means pick a (calendar) day and then compare the two values for that same (calendar) day. The WG long ago considered alternatives, determined that all alternatives gave rise to some unintuitive results, and for uniformity picked one way for all the date/time datatypes that seemed to be least unreasonable. When in doubt, compute the actual timeOnTimeline values. > > and why the incomparable range is 24 hours wide > > (I would think 28). > > You may be right on this one. I'll have to chew on it for a while. Perhaps tricky to envision, but imagine a timeline of 52 hours. The day of timezone +14:00 begins earliest and ends 24 hours later. Other days start later and end later; finally the day of timezone -1400 begins four hours after the earliest day (+14:00) ends. Given any untimezoned time xx:yy:zz, any timezoned time whose timeOnTimeline is within the interval (bounded by the timeOnTimeline of) xx:yy:zz+14:00 and xx;yy:zz-14:00 is incomparable with xx:yy:zz, This interval is 28 hours wide. time values whose timeOnTimeline is outside this interval will be comparable. So Sandy is correct: 28 hours wide. I've scanned through the sections defining the various date/time datatypes; the time section appears to be the only place where the width of the "incomparable interval" is mentioned. Formal proposal: In the Note quoted in comment 0, replace '24 hours' by '28 hours'.
WG approved a single character change: Formal proposal: In the Note quoted in comment 0, replace '24 hours' by '28 hours'.
The change described in comment 4 has now been integrated into the status-quo documents. I am accordingly marking this issue resolved. Sandy, as the originator, if you would signal your acceptance or rejection of this resolution by closing or reopening the bug in the usual manner, it would be helpful. If the working group does not hear otherwise from you in the next two weeks, we will assume that you are content with the disposition of this comment.