[Bug 1334] no implicit conversion between time zones

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1334





------- Additional Comments From mike@saxonica.com  2005-07-12 08:14 -------
OK, let's looks at the four ideas that Andrew put on the table:

We considered a number of alternatives:

A- disallow comparison of values with timezones to those without timezones

B- define pairs of subtypes that require a timezone and do not allow a
timezone, respectively. Comparison would only be allowed on these subtypes.

C- infer Z if no timezone was specified

D- allow every comparison operator to specify a timezone that would be used
for values without a timezone

The main problem with A is that with many comparisons, one of the operands is
current-date(). It doesn't seem reasonable that

current-date() gt xs:date('2000-01-01') 

should be an error on the grounds that current-date() has a timezone and the
other date doesn't. 99% of users would be amazed to discover that dates are
allowed to have timezones anyway. Providing additional functions to return the
current date/time without a timezone gets ridiculous.

B would be nice if Schema had done it this way in the first place, but they
didn't. We want queries to work with existing documents and schemas, we don't
want everyone to have to redesign their data so they can query it. Yes, this is
the solution we adopted with durations - but they are used far less frequently
than dates and times.

C is a subset of the solution we have adopted. We allow the implementation to
determine what the implicit timezone should be, and Z is one of the options. An
implementation is even allowed to use Z without giving the user the option to
choose something different. As someone who happens to live in timezone Z for
half the year, I would personally be quite happy using an implicit timezone of
Z, but people from other parts of the world seem to have different preferences.
There's no intrinsic reason to choose one timezone rather than any other as the
implicit timezone, so it seems reasonable to allow implementations to make it
configurable. 

D is just overly cumbersome. Again, given the example 

current-date() gt xs:date('2000-01-01') 

forcing users to tell us what timezone they had in mind is just plain unfriendly.

So: please accept that this is a difficult problem with no obviously right
answer. Many people can legitimately have different views on which of the
imperfect solutions is least bad. We've done our best to find something that
works, and it does work reasonably well for most use cases.

Going back to my original remark that there is nothing we can do when authors of
two different documents assume two different timezones, there is of course
something we can do: we can encourage them to specify the timezone explicitly.
If they do that, everything works fine. If they don't, they get what they
deserve, which is a "roughly correct" ordering that's fine to a certain level of
precision, of around one day - which as it happens is good enough for very many
applications, since far more people use dates than use times.

Michael Kay

Received on Tuesday, 12 July 2005 08:14:29 UTC