W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1334] no implicit conversion between time zones

From: <bugzilla@wiggum.w3.org>
Date: Thu, 14 Jul 2005 07:03:55 +0000
To: public-qt-comments@w3.org
Message-Id: <E1DsxlD-0003pq-Cl@wiggum.w3.org>


------- Additional Comments From duerst@it.aoyama.ac.jp  2005-07-14 07:03 -------
(In reply to comment #7)
> The reason why it is as it is has to do with the following:
> In order to be able to order or optimize filters that include comparisons on 
> date/time values wit the help of indices you need to be able to have the 
> values in a complete order (as Andrew explains).

Acknowledged. There is more than one solution that allows this
easily, and avoid the problems that we point out.

> If you have several documents that contain values that have differently 
> implied timezones, you should do one of two things:

Who is 'you'? This is the World Wide Web. Documents and data
get passed around. Writing as if documents were used in small
contexts, with tight control and knowledge, is completely out of data.

> 1. Use the adjust-timezone functions for each document value based on the 
> local timezone.

Fine, except that we have to help people to use them from the start,
to make sure that there won't be any bad awakenings.

> 2. Lobby your implementation to provide a mapping to a timezone when storing 
> the document (thus loosing the "absence" of the timezone).

This may not be the right solution. There are cases where there
is truely no timezone.

> The reason that we imply exactly one timezone is that we need something that 
> can be implemented without having too much implementation complexity. 

That's fine.

> Note that implementations can and some will default to Z...

Great in some sense, but even worse in some other: The cases
where it by chance 'just works' (whatever 'it' be) are more,
but that only means that the surprising and unpredicted consequences
may hit harder when they finally hit.

Regards,   Martin.
Received on Thursday, 14 July 2005 07:03:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC