- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 14 Jul 2005 07:11:20 +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:11 ------- (In reply to comment #8) [reply split into two parts] > So: please accept that this is a difficult problem I think we agree on that. >with no obviously right > answer. Maybe no obviously right one, but clearly better and worse ones, and the current one is on the worse side, unfortunately. >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. Well, except when data from different sources (from different parts of the world,...) get combined, or servers moved from one timezone to another, and so on. > 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. The best way to encourage them would be to make sure they do it right from the start (either they only have timezoned data, or they have other info in their data, such as a location,...). Using different types is best in this regard. Using a Z default probably gets this done to quite some extent. > 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. See separate comment re. dates. Regards, Martin.
Received on Thursday, 14 July 2005 07:11:23 UTC