This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The date/time values specify that leap seconds are not to be handled. There are a few minor points to note. The definition of leap second in the document says leap seconds can only occur on some months, whereas ITU-R TF.460 allows for them at the end of any month. For almost a decade the ITU-R has been discussing abandoning leap seconds. The process is closed and involves international diplomatic consensus. There is no way to predict the outcome. Nevertheless, any outcome has implications for the date/time values. If the status quo persists, then leap seconds will continue and the document already specifies their handling. If leap seconds are abandoned altogether, then in about 600 years most nations will probably choose to shift their timezone offsets from UTC, and that will likely drive some zone offsets beyond the 840 minute limit which the schema draft currently specifies. This is clearly not an urgent issue, but one which does affect posterity. If the ITU-R decides to keep leap seconds in UTC, but remove them from the broadcast time scale by changing its name, then many of the definitions of terms will change. The likely result is that POSIX time_t will become leap free while UTC becomes just another timezone offset. In that case the timezone offsets will increment by one second for each leap second in UTC. This sort of change could come into effect within 10 years. Whereas POSIX allows zone offsets of seconds, the current XML schema with its specification of minutes could be problematic. This depends on whether the date/time is intended to give the offset from whatever is called UTC, or from POSIX time_t. If the latter, then the schema would want to allow zone offsets measured in seconds.
[Speaking for myself] The WG decided a while back that trying to keep leap-seconds properly documented was a time sink. It appears to me that we've continued to maintain too much detail. Suggestion: 1) Adopt the following definition for D.2 [Definition:] A leap-second is an additional second added when an adjustment is deemed necessary by the International Earth Rotation and Reference Systems Service in order to keep ·UTC· within 0.9 seconds of observed astronomical time. When leap seconds are introduced, the last minute in the day has more than sixty seconds. (See [International Earth Rotation Service (IERS)], [ITU-R TF.460-6].) Leap seconds are not supported by the types defined here. 2) remove all other discussion. The WG should not be in the business of describing leap seconds.
[speaking for myself] Thank you for the comments. I plead guilty to the error in the definition of leap second. I would fix it by changing "added to the last day of December, June, October, or March" to "added to the last day of a month (by preference December, June, October, or March)", but I can also live with the proposal in comment 1, which I take to amount to "delete 'to the last day of December, June, October, or March' and 'such'". (It also suggests deleting "all other discussion", but I would prefer to keep changes to a minimum.) With regard to the possible effects of an abolition of leap seconds; if it appears likely that civil authorities will increase their offsets from UTC (rather than UTC introducing a leap hour once it is about an hour off of solar time), then I believe a future version of the XSD specification (if there are any) might usefully relax the maximum offset for date / time values. I don't pretend to understand the ins and outs of Posix time handling, and with respect to the last paragraph of the issue description note only that the spec describes the offset as an offset from UTC, not from Posix time_t. I hope rather than affirm that this means no adjustment to the text is necessary in order for the behavior of XSD types to be well defined in the event that the scenario described in the issue description comes to pass.
(In reply to comment #2) > respect to the last paragraph of the issue description note only that the spec > describes the offset as an offset from UTC, not from Posix time_t. I hope > rather than affirm that this means no adjustment to the text is necessary in > order for the behavior of XSD types to be well defined in the event that the > scenario described in the issue description comes to pass. There is no telling what the ITU-R will decide, but there is another possible scenario. The laws of some countries specify mean solar time, and it is possible that their reaction to a UTC without leap seconds would be to add subsequent leap seconds into the zone offset for their own jurisdiction. Again whereas the POSIX specification currently can handle this, in this case the XML Schema specification would fail to represent the time zone of any such countries because their zone offsets would no longer be integer minutes. The indications from the status quo are that the UK, Denmark, and China all consider mean solar time more important than atomic time. The long history of time scales shows that any scale controlled by someone else is subject to change its characteristics at their whim. It is very hard to future-proof a standard against this, but allowing zone offsets of seconds would both match the capabilities of POSIX and handle the most plausible zone scenarios.
I think it would be foolish to try and anticipate changes to the civil standards for measuring time. For all we know, they'll switch in a few years' time to having 10 hours of 100 minutes in each day.
The WG agreed to the following change (the first suggested change in comment #2 from Michael Sperberg-McQueen below). The WG further decided not to disturb other areas of the spec that refer to leap-seconds. Change: "added to the last day of December, June, October, or March" to: "added to the last day of a month (by preference December, June, October, or March)"
The change described in comment 5 has now been integrated into the status quo documents, so I'm marking this issue resolved. Steve Allen, as the originator of the bug report, should get an email notification of this change of status. As the originator, you have the right to signal whether you are satisfied with the consideration given by the WG to your comment and with the final disposition of the issue. If you are satisfied with the disposition (or willing to acquiesce in it), please so indicate by closing the issue in Bugzilla. If you are unhappy and wish the WG to reconsider, please reopen the bug report and indicate in a comment what changes in the spec would satisfy your concerns. If we don't hear from you within the next two weeks, we will assume that you are happy with the result. Thank you, in any case, for your interest and comment.
(In reply to comment #6) The change makes the description of leap seconds congruent with ITU-R TF.460. The other issues are too prospective for definitive action. I note one further editorial nit. The XML Schema doc uses the phrase "Universal Coordinated Time", whereas the definition in the ITU-R doc gives the English phrase as "coordinated universal time" (initial capitals not necessary). For reference, the best coverage of UTC activity in the ITU-R is often found in the CGSIC proceedings, this year's are at http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/49th_CGSIC_Meeting_Agenda.htm The overview of this year's ITU-R actions can be seen in Lewandowski http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/Reports/%5B39%5DTiming_WL_General.pdf and Beard http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/Reports/%5B41A%5DITU_future_UTC_CGSIC_49th.pdf