Re: timestamp with time zone a la sql99

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