From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, "alvherre(at)alvh(dot)no-ip(dot)org Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: storing TZ along timestamps |
Date: | 2011-07-21 23:05:36 |
Message-ID: | 1F4E5F93-3241-4420-B54C-5A368860FF69@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 21, 2011, at 5:30 PM, Christopher Browne wrote:
> - I'd commend capturing NOW() in a timestamptz field. That gives you:
> 1. What time the DB server thought it was, in terms of UT1
> 2. What timezone it thought was tied to that connection.
Except that it doesn't, and that's exactly the problem I'm trying to solve here. I want to know what timezone we were using when we put a value into timestamptz, which then got converted to UT1. Without a reliable way to store what the timezone *was* at that time, we have no way to go back to it.
Now, we can debate whether it makes more sense to store the original time without conversion to UT1, or whether we should store the time after converting it to UT1 (or whether we should offer both options), but that debate is pointless without a good way to remember what timezone it started out in.
Arguably, we could just create an add-on data type for storing that timezone information, but that seems pretty daft to me: you're stuck either storing raw text which takes what should be a 12 byte datatype up to a 20-30 byte type (8 byte timestamp + varlena + text of timezone name), or you end up with major problems trying to keep an enum in sync with what the database has available in it's ZIC database.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-07-21 23:10:46 | Re: spinlock contention |
Previous Message | Florian Pflug | 2011-07-21 23:03:28 | Re: sinval synchronization considered harmful |