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.

--Magne

---------------------------(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
      match

Reply via email to