- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 14 Jul 2005 07:03:55 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1334 ------- 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