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: Tue, 12 Jul 2005 03:08:27 +0000
To: public-qt-comments@w3.org
Message-Id: <E1DsB8F-0001iK-FE@wiggum.w3.org>


------- Additional Comments From duerst@it.aoyama.ac.jp  2005-07-12 03:08 -------
(In reply to comment #4)
[personal comment]

> Of course it might be true that the author of one document using a zoneless 
> was thinking of GMT, while the author of another document using a zoneless 
> was thinking of EST. 

Trying to talk this problem away with 'might' doesn't help at all. 
As long as the world is round, different authors WILL assume different time 
zones, period.

> There's really not much we can do about that. 

Of course, there is A LOT that can be done about it. Andrew Eisenberg
in his comment #2 mentioned four solutions that the WG looked at; at
least the first three of them significantly improve the situation.
(Unfortunately, Andrew's comment does not indicate any of the reasons
for why these solutions were rejected.)
(The fourth solution in Andrew's comment #2 is more like syntactic
sugar, moving the potential conversion from a function on one (or both)
operands to a potential attribute of the operand, and thus does not
address the problem.)
Other solutions would include a mandatory parameter on the whole query
defining the assumed time zone for dates/times without timezones (for
any query that contained any date/time-related operations; assuming
for the moment that it's possible to figure this out, which it may
not, in which case the mandatory parameter would have to be there
for all queries).

> The solution
> we have is not intended to be perfect,

Thanks for admitting that.

> it's intended to be a pragmatic compromise,

A compromize between what and what? Of all the proposals, it looks like the 
worst solution to me, which a compromize never should be.

> and as such, not much will be achieved by pointing out its
> deficiencies unless a better solution is put on the table.

Please see Andrew's comment #2, and above.    Regards,   Martin.
Received on Tuesday, 12 July 2005 03:08:35 UTC

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