Tom Lane wrote:
As an example, timestamptz '2007-01-01 00:00 -05' + interval '6 months'
must yield 2007-07-01 00:00 -05 according to the spec, AFAICS; but most
people living in the EST5EDT zone would prefer to get midnight -04.
There are probably some folk in South America who'd prefer midnight
-06. (Looks at a map ... hm, maybe not, but certainly Europe vs
Africa would produce some such examples.)
Correct me if I'm wrong, but IIRC there is no universally accepted
canonical list of time zone names (labels). By using the name, instead
of the offset, you are not guaranteed that one database client can even
understand the timestamp entered by another client (unless the database
contains its own definition which is backed up and restored together
with the data).
I clearly understand the problems (having written calendar applications
myself) of not relating the time to the specific time zone, but I think
not adhering to the standard is much worse. If you're only interested
in one time zone, simply use WITHOUT TIME ZONE, and you're good. if
you're working in multiple time zones, the arithmetic and handling will
be complex (and maybe not even deterministic).
I think the resolution and presentation of local time is best handled by
an application level, and not by the database.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not