This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6046 - Why does range of legal time zone offsets exceed actual usage?
Summary: Why does range of legal time zone offsets exceed actual usage?
Status: RESOLVED WORKSFORME
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL: http://lists.w3.org/Archives/Public/w...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-09 02:10 UTC by C. M. Sperberg-McQueen
Modified: 2008-09-24 20:24 UTC (History)
2 users (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2008-09-09 02:10:14 UTC
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.
Comment 1 C. M. Sperberg-McQueen 2008-09-09 02:57:15 UTC
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.
Comment 2 Michael Kay 2008-09-09 08:11:14 UTC
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.
Comment 3 Michael Kay 2008-09-09 08:21:11 UTC
>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.
Comment 4 C. M. Sperberg-McQueen 2008-09-12 16:44:00 UTC
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.
Comment 5 Peter F. Patel-Schneider 2008-09-24 20:24:46 UTC
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.