Re: storing TZ along timestamps

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Jim Nasby <jim(at)nasby(dot)net>
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-03 09:56:22
Message-ID: 1307094982.32120.2.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On tor, 2011-06-02 at 22:58 -0500, Jim Nasby wrote:
> I'm torn between whether the type should store the original time or
> the original time converted to GMT. I believe you would have the most
> accuracy if you stored the original time... but then indexing becomes
> problematic. I don't know if this data quality issue can be solved by
> anything short of somehow storing the actual timezone rule that was in
> place when the data was set.
>
> Speaking of input; someone asked what timezone should be used as the
> "original" timezone. We should use whatever timezone was passed in
> with the value, and if one wasn't passed in we should use whatever the
> timezone GUC is set to (I'm assuming that's what timestamptz does).

I think all of that comes down to business rules. Train and airline
companies etc. have probably figured this out for themselves, not
necessarily consistent with each other. So it's doubtful whether a
single solution that we can hash out here is going to work well in
practice. I think making it easier to implement particular business
rules in this area in userspace (composite types, etc.) might go a
longer way.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-06-03 10:04:24 Re: SSI predicate locking on heap -- tuple or row?
Previous Message Pavel Golub 2011-06-03 05:54:13 Re: [HACKERS] PQdeleteTuple function in libpq