[Bug 1334] no implicit conversion between time zones

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





------- Additional Comments From duerst@it.aoyama.ac.jp  2005-07-14 07:44 -------
(In reply to comment #8)
> OK, let's looks at the four ideas that Andrew put on the table:

> 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.

Agreed. It really doesn't make much sense. During the XML Schema
discussion, I proposed to have only a restricted set of (sub-)types,
and I think I left out dates-with-timezones explicitly.

>Providing additional functions to return the
> current date/time without a timezone gets ridiculous.

Well, no, having a function that returns the date with a timezone
in the first time might be called ridiculus. The situation can
easily be fixed: Have current-date() return the date without a
timezone. That alone will take care of most of the problems.
For those people who think that a date needs a timezone, something
like current-date-with-timezone() can be added at low additional
implementation cost, if considered necessary.


> 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.

It would be extremely nice if you did the right thing, given that
you acknowledge that it's the right thing. People who designed their
applications carefully will already have made sure that they
distinguish between timezoned and non-timezoned stuff. Those who
haven't done that will have to do that sooner or later anyway,
either on the schema level or on another (query or application,...).
People who will find the new types will have an easier job designing
there applications in a better (clearer, less buggy, more
interoperable) way.


> 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. 

What is it that lets you over and over forget that this is the
World Wide Web Consortium, not the Local My Data Only Consortium?
Of course there is no intrinsic reason to choose one time zone
or another, but there are very strong reasons, and benefits,
to choose a single timezone (as opposed to 'whatever the
implementation or the setting happens to be).


> 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.

For that specific case, I fully agree. But that can be easily
fixed, and in general, it's better to make sure the users are
aware of the problem than to let them stumble.


Regards,   Martin.

Received on Thursday, 14 July 2005 07:44:27 UTC