Josh Berkus <[EMAIL PROTECTED]> writes:
>> 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.
Well, that is *exactly what I'm talking about*. I want timestamp with
time zone to carry "US/Arizona" not just "-07". Obviously there needs
to be some option to get the latter displayed when that's all you want,
but internally a value of the datatype needs to be able to carry full
knowledge of which timezone it's supposed to be in. Dumbing that down
to a simple numeric GMT offset isn't good enough.
>> 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?
It just doesn't talk about it AFAICS.
To comply with the spec we definitely need to be *able* to support
timezone values that are simple numeric GMT offsets. But I think we
ought also to be able to store values that are references to any of
the zic database entries. This looks to me like a straightforward
extension of the spec.
We went to all the trouble of importing src/timezone in order that we
could make a significant upgrade in our timezone capability, and now
it's time to take the steps that that enables. Before we were limited
to the lowest-common-denominator of the libc timezone routines on all
our different platforms, but now we are not...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
