Re: Timezone database changes

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

On 10/11/07, Magne Mæhre <Magne(dot)Mahre(at)sun(dot)com> wrote:
> Trevor Talbot wrote:
> > Thinking that it might have had out of date zone rules brings up an
> > interesting scenario though. Consider a closed (no networking or
> > global interest) filing system in a local organization's office, where
> > it's used to record the minutes of meetings and such via human input.
> > It would seem that the correct time to record in that case is in fact
> > the local time, not UTC. If that system is left alone for years, and
> > does not receive any zone rule updates, it will likely begin storing
> > the wrong UTC values. When the data is later transported out
> > (upgrade, archive, whatever), it will be incorrect unless you use that
> > particular snapshot of the zone rules.
> >
> > That situation might sound a bit contrived, but I think the real point
> > is that even for some records of observed times, the local time is the
> > authoritative one, not UTC.
>
> ...and for that scenario you have TIMESTAMP WITHOUT TIME ZONE

But that doesn't give you DST-sensitive display for free, which is
tempting for application use, especially if the application is meant
to be suitably generic.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message andy 2007-10-11 13:41:47 Re: full text search in 8.3
Previous Message Magne Mæhre 2007-10-11 12:16:33 Re: Timezone database changes