Re: storing TZ along timestamps

From: Jim Nasby <jim(at)nasby(dot)net>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: storing TZ along timestamps
Date: 2011-06-06 06:50:24
Message-ID: ECA252D8-C4E6-4CBF-8C47-DD958BD1664F@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
> On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>>
>> I'm torn between whether the type should store the original time or the original time converted to GMT.
>
> This is the wrong way to think about it. We *never* store time
> "converted to GMT". When we want to represent a point in time we
> represent it as seconds since the epoch.
Right. Sorry, my bad.

> The question here is how to represent more complex concepts than
> simply points in time. I think the two concepts under discussion are
> a) a composite type representing a point in time and a timezone it
> should be interpreted in for operations and display and b) the
> original input provided which is a text string with the constraint
> that it's a valid input which can be interpreted as a point in time.

My fear with A is that something could change that would make it impossible to actually get back to the time that was originally entered. For example, a new version of the timezone database could change something. Though, that problem also exists for timestamptz today, so presumably if it was much of an issue we'd have gotten complaints by now.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-06-06 06:54:48 Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous Message Pavan Deolasee 2011-06-06 06:36:01 Re: heap vacuum & cleanup locks