> But the current timestamp does not store a timezone. timestamp with time zone
> is supposed to store and output the timezone that was inserted.
> The current timestamp has it messed up (sorry), since it does not store a timezone.
> It stores time in UTC and always converts output to the timezone derived from [PG]TZ.
Good point, but I'll disagree with the implied conclusion. imho the
SQL9x provisions for time zone handling are fundamentally and tragically
broken, with absolutely no provisions for DST, time zone shifting, etc
etc. Which helps lead most folks to code other databases without time
zones at all.
Date and Darwen (1997) have essentially the same opinion (though the
last sentence is my own speculation).
> IMHO timestamp is currently closest to the ANSI timestamp without time zone.
> Especially if you always omit a timezone for input and ignore the timezone that is output.
Hmm. My thought was to implement a timestamp type without *any* time
zone manipulation, leaving our current type as the "zone-full" one, but
it should be discussed whether we need a high-fidelity implementation of
the fundamentally useless SQL9x version. fwiw, I did implement "time
with time zone", which was easy, mostly to "check the feature box" and
I'll guess that no one bothers to use it.
Comments?
- Thomas
