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:11:20 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DsxsO-0004An-TS@wiggum.w3.org>

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

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