Josh Berkus <[EMAIL PROTECTED]> writes:
> The reason is simple: our current implementation, which does include DST,
> does not include any provision for the exceptions to DST -- such as Arizona
Say what?
regression=# set timezone to 'MST7MDT';
SET
regression=# select now();
now
-------------------------------
2004-10-25 11:52:47.093538-06
(1 row)
regression=# set timezone to 'US/Arizona';
SET
regression=# select now();
now
-------------------------------
2004-10-25 10:52:49.441559-07
(1 row)
> -- or for the difference between "1 day" and "24 hours". (Try adding "30
> days" to "2004-10-05 10:00 PDT", you'll see what I mean).
This is the point about how interval needs to treat "day" as different
from "24 hours". I agree with that; the fact that it's not done already
is just a reflection of limited supply of round tuits. I think it's
orthogonal to the question of how flexible timestamp with time zone
needs to be, though.
> Nor do I see a way out of this without raising the complexity, and
> configurability, level of timezones significantly.
This does not seem to me to be an argument why timestamp with time zone
ought to be incapable of dealing with DST-aware time zones. That simply
guarantees that calendar apps won't be able to use the datatype. If
they still can't use it when it can do that, then we can look at the
next blocking factor.
> So if we're going to be broken (at least from the perspective of calendar
> applications) we might as well be broken in a spec-compliant way.
I have not said that we can't comply with the spec. I have said that
our ambitions need to be higher than merely complying with the spec.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
