From: | Magne Mæhre <Magne(dot)Mahre(at)Sun(dot)COM> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Trevor Talbot <quension(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Timezone database changes |
Date: | 2007-10-11 12:16:33 |
Message-ID: | 470E1421.9090709@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Trevor Talbot | 2007-10-11 12:48:07 | Re: Timezone database changes |
Previous Message | Magne Mæhre | 2007-10-11 12:06:19 | Re: Timezone database changes |