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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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