Re: Timezone database changes

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Trevor Talbot" <quension(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magne Mæhre <Magne(dot)Mahre(at)sun(dot)com>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Timezone database changes
Date: 2007-10-12 10:07:10
Message-ID: 200710121207.10945.peter_e@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Am Donnerstag, 11. Oktober 2007 schrieb Gregory Stark:
> Thinking of it as UTC is the wrong way to think about it. A birth occurred
> at a specific moment in time. You want to record that precise moment, not
> what it happened to show on the clock at the time. If the clock turns out
> to have been in the wrong timezone the birth isn't going to move.
>
> The use case for storing a local timestamp with a timezone attached is for
> things like appointments. If the time zone rules change you would want the
> appointment to move with them, not to stay at the same moment in time.

The difference here is that one occured in the past and one is planned for the
future. Appointments in the past will still stay at the same time even if
the time zone rules change afterwards.

The supercorrect way to handle this would likely be to introduce some sort of
time-zone rules changeset that describes "as of point in time X, the time
zone designation ABC changes in the following way", which would then fix up
all data items past point X in the database in some clever way. Obviously
this is quite a bit too much for us to manage.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-10-12 10:41:17 Re: ECPG regression tests
Previous Message Andreas Joseph Krogh 2007-10-12 09:55:37 Re: Including Snapshot Info with Indexes