Re: storing TZ along timestamps

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Ian Caulfield <ian(dot)caulfield(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: storing TZ along timestamps
Date: 2011-07-21 21:52:57
Message-ID: 21508.1311285177@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <jim(at)nasby(dot)net> writes:
> On Jul 19, 2011, at 11:22 AM, Ian Caulfield wrote:
>> There was an earlier point made that if someone puts eg 5pm local time
>> two years in the future into the database, and then the DST boundary
>> gets moved subsequently, some applications would like the value to
>> still say 5pm local time, even though that means it now refers to a
>> different point in absolute time - this potentially seems like a
>> useful feature. Retroactive timezone changes wouldn't make a lot of
>> sense in this case though...

> Right; and timezone's aren't supposed to change retroactively. The ZIC database is specifically setup so that it knows the history of TZ changes and deals with the past correctly.

You haven't noticed that at least two or three times a year, there are
"historical corrections" in the ZIC database? The mapping between local
time and UTC might be less likely to change for a time instant in the
past than one in the future, but it would be folly to assume that it's
immutable in either direction.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2011-07-21 22:00:50 Re: proposal: new contrib module plpgsql's embeded sql validator
Previous Message Jim Nasby 2011-07-21 21:48:27 Re: storing TZ along timestamps