Tom,
> regression=# set timezone to 'US/Arizona';
> SET
> regression=# select now();
> now
> -------------------------------
> 2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
Of course, it would be very helpful if the result above could display
"Arizona" instead of the non-specific "-07", but I'm pretty sure that's
already a TODO.
> 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.
Well, when I first brought up the issue (2001) I was shot down on the basis of
spec-compliance, since SQL92 recognizes only Year/Month and
Day/Hour/Minute/etc. partitions. Glad it's up for consideration again.
Come to think of it, it was Thomas Lockhart who shot down the idea of fixing
Interval, and he's retired now ...
> 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.
That's definitely a progressive attitude .... pardon me for being pessimistic.
> 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.
Hmmm ... well, does the spec specifically prohibit DST, or just leave it out?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco