> Proposal #1: TIMESTAMP WITHOUT TIME ZONE as default
Hmm. Already done for 7.3 :)
7.2 introduced that data type, and 7.1 did not have it, so we had one
release cycle to allow dump/restore to do the right thing.
> Proposal #2: We need more time zones.
The other complaint is that we have too many time zones. Certainly it is
not ideal (but it may be optimal from an execution time standpoint) that
these time zones are hardcoded into lookup tables; moving these into
external files will be *much* slower, moving these into database tables
will be somewhat slower. But asking us to deal with Arizona may be a bit
too much; those guys do things just to be different ;)
btw, on my Linux box the time zone rule is 'US/Arizona', as in
lockhart=# SET TIME ZONE 'US/Arizona';
My Linux box thinks that for Arizona time input would always be in
'MST', which is recognized by the PostgreSQL date/time parser so things
are handled consistantly (at least until I upgrade glibc :((
Let's see how the glibc breakage discussion pans out. I haven't worried
about pre-1903 dates and times because time zones were not as
standardized then as they are today. But if we end up rolling our own
then we might consider pulling more of this into the backend and getting
rid of our y2038 problems at the same time :))
- Thomas
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
