Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Fri, 22 Oct 2004, Tom Lane wrote:
>> than having two different types (the idea of a GUC variable to choose
>> which one is selected by a given type name is just horrid).
> That is needed no matter what change you do if you want old programs that
> use the current timestamp with time zone to work. Today you don't get back
> the same time zone as you insert, programs might depend on that.
[ shrug... ] We've made much larger changes than that in the name of
standards compliance. In practice I think the majority of apps are
working in contexts where they will get back the same zone as they
inserted, if they inserted a zone explicitly at all, so the risk of
breakage is not that high. Having a GUC variable that changes the
semantics underneath you is *much* riskier, to judge by past experience.
>> We are not fully there yet (can't do AT TIME ZONE conversions with all
>> zones yet, for instance)
> Why is that?
Because it's not done yet. There's a set of GMT-offset-only zone names
wired into the datetime code (look in the "datetime token table") and
those are what AT TIME ZONE knows how to deal with. We need to unify
that old stuff with the src/timezone code, but we ran out of time to do
it in 8.0.
The way I see it, we have three sorts of zones to deal with: fixed
numeric offsets from UTC, names that represent fixed offsets (eg, "EST"
is the same as UTC-5), and names that represent DST-variable offsets
(eg, "EST5EDT"). For what are now entirely historical reasons, various
parts of the system cope with different subsets of these three types.
I want to get to a state where you can use any of them in any context
and it Just Works. (While we are at it, we need to make the set of
recognized zone names user-configurable; the australian_timezones kluge
satisfies our contributors Down Under, but there are a lot of unhappy
people still, because for instance IST means different things in Israel
and India.)
regards, tom lane