6046 2008-09-09 02:10:14 +0000 Why does range of legal time zone offsets exceed actual usage? 2008-09-24 20:24:46 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.1 only Macintosh Mac System 9.x RESOLVED WORKSFORME http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0135.html P2 normal --- 1 cmsmcq cmsmcq mike pfps www-xml-schema-comments oldest_to_newest 21835 0 cmsmcq 2008-09-09 02:10:14 +0000 In email to the XML Schema comments list on 5 September 2008 (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0135.html), Peter F. Patel-Schneider raised the following issue (among others): 1/ Time instants ... 1.4/ Range of possible timezone values The WG does not find a justification for having the range of timezone be -840 to +840. The range of timezones currently in use ranges from UTC-12 to UTC+14 (http://en.wikipedia.org/wiki/List_of_time_zones), i.e., -720 to +840. The WG suggests that the range of timezones be limited to those actually in use to tighten comparisons between dateTime values with and without timezones. 21841 1 cmsmcq 2008-09-09 02:57:15 +0000 Thanks for the comment. In setting the upper and lower bounds for the time zone offset portion of the seven-property model, the XML Schema WG was motivated to provide a little extra room, going beyond current usage, in order to ensure that the type would not need to be redefined if some jurisdiction chose to change the offset of its civic time to UTC. If memory serves, this happened as recently as 1999, when some jurisdictions in the Pacific vied to be the first inhabited bits of land to see the new millennium come. Note that the definition of the type over-generates here in another way, as well: it allows for offsets of arbitrary numbers of minutes, even though almost all jurisdictions define civil time in terms of an integral number of hours offset from UTC, a few using half-hours, and only one that I know of using an offset which is on the UTC quarter-hour. Any sanity check that seeks to ensure that the offset given is an offset actually in use will need to do more than restrict the upper bound. Speaking for myself, I am a bit concerned that the upper and lower bounds on the type don't give more breathing room for further changes of this sort. But compatibility issues will make it difficult to change the bounds, in any case. 21845 2 mike 2008-09-09 08:11:14 +0000 Personal response: The limit of +/- 14 hours was specified in XSD 1.0 and it is not now possible to gratuitously reduce the range. I have no idea why it was specified that way, but that's now immaterial. You can't change the rules for a basic data type 7 years after publishing the spec. Since this aspect of the specification is unchanged from XSD 1.0, this bug appears to have been misclassified: it is a comment on the 1.0 specification, not on the 1.1 last-call draft. 21846 3 mike 2008-09-09 08:21:11 +0000 >Speaking for myself, I am a bit concerned that the upper and lower bounds on the type don't give more breathing room for further changes of this sort. Indeed, there seems to be some evidence that in order to persuade people to get up earlier in the morning, countries are putting the clocks forward at an average rate of about one hour every fifty years, which means that in around 1000 years the UK will be on GMT+24. However, the trend is one-way, and there seems to be little risk that the "unused" timezones -13:00 and -14:00 will ever be adopted. 21879 4 cmsmcq 2008-09-12 16:44:00 +0000 The XML Schema WG discussed this issue on its telcon today. The upshot was, first, that most of those on the call were disinclined to regard the range allowed for timezone offsets as a bug, and second that even if one agrees that there is a bug in the range, it would not be possible to change it now, for backward compatibility with XSD 1.0 and with the deployed software supporting XPath Functions and Operators. We noted that if the over-generous range poses a problem for an application, and one wishes for tighter validation, it is possible to use the pattern facet to define a more restrictive subtype. (Or to use the enumeration facet to enumerate the offsets which are actually in use for a given period.) Under the circumstances, we regret that we don't see a way to reolve this issue as suggested by the OWL Working Gropu, and so we are marking the issue WORKSFORME. If the OWL WG is content with this disposition of the issue, we ask that they let us know by adding a comment to that effect to this issue; if the OWL WG is not content and wishes to reopen or to appeal the decision, please indicate in the same way. If we don't hear otherwise from OWL in the next two weeks, we will assume that you are content (if reluctantly so) with the disposition just described. 22033 5 pfps 2008-09-24 20:24:46 +0000 OK, I guess. Grumble, grumble. In any case, it is unlikely to affect OWL per se, as OWL is heading towards requiring timezones, and requiring missing timezones to be filled in before the data hits OWL.