Skip site navigation (1) Skip section navigation (2)

Re: storing TZ along timestamps

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: storing TZ along timestamps
Date: 2011-05-27 21:32:37
Message-ID: 4DDFD225020000250003DE1C@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
"David E. Wheeler" <david(at)kineticode(dot)com> wrote:
 
> I like it, but what do you do when a TZ has been renamed or has
> ceased to exist. Or, worse, existed last week, so last week's
> dates might still use it, but next week's must not?
 
I think the key thing is that the timestamp portion of it would be
identical to our current TIMESTAMP WITH TIME ZONE -- always store it
in the value UTC zone.  That way comparisons and math between
timestamps could remain sane.  The stored time zone portion would be
what it would be the display format, if usable.  In an extreme
situation like you describe above, I guess you could fall back on
what we do now for display of a timestamptz value.
 
Personally, I think it would be good to move a bit closer to the
standard by including a time zone in a TIMESTAMP WITH TIME ZONE
value.  The biggest problem I can see is how to try to do this in a
standard conforming fashion without breaking existing code.  It
would seem more than a little odd to support the standard semantics
with nonstandard syntax and vice versa.
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-05-27 21:35:41
Subject: Re: storing TZ along timestamps
Previous:From: Peter EisentrautDate: 2011-05-27 21:24:14
Subject: Re: How can I check the treatment of bug fixes?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group