Dennis Bjorklund <db@zigo.dhs.org> writes:
> You don't need to be satisfied with it. I think a type like the above
> would be fine to have. It should however not be called "TIMESTAMP WITH
> TIME ZONE" because there is already a definition of that type. We can not
> hijack standard types.
Sure we can, as long as they are upward compatible with the standard
behavior. The spec says you can put a numeric-GMT-offset zone in and
get a numeric-GMT-offset zone out. We can do that and also support
named, possibly DST-aware zones. This seems a whole lot better to me
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).
>> But storing a fixed GMT offset is going to be a step backwards compared
>> to existing functionality.
> It's not a step backwards since you can do everything you can do with the
> current type plus a little bit more.
... except get useful answers from interval addition ...
> What would you store when the user supplies a timestamp like '2004-10-22
> 17:21:00 +0200'. Should you reject that because you don't know the
> time zone name?
You are attacking a straw man.
We have put a great deal of work into 8.0 to add the ability to support
real-world zones fully. We did not import src/timezone because we
needed it to implement the SQL spec; we did so because we needed it to
implement what real users want. We are not fully there yet (can't do AT
TIME ZONE conversions with all zones yet, for instance) but I am hoping
to be there by 8.1. It would be folly to invent a timestamp with time
zone type that is going in the other direction while we are trying to
bring the rest of the system up to full speed by allowing all timezone
kinds everywhere.
regards, tom lane
