On 10/4/14, 3:25 PM, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 03:01:45PM -0500, Jim Nasby wrote:
On 10/4/14, 2:58 PM, Bruce Momjian wrote:
I've committed changes for this in advance of the upcoming 9.4beta3
release. Hopefully, if this is seriously bad for anyone, we'll hear
about it from beta testers before it gets into any official back-branch
releases.
The changes for the Russian Federation timezones taking effect October
26 reinforces our need to get a new set of minor releases out soon. In
fact, those storing future dates might already need those updates.
This is why I wish we had a data type that stored the timezone that was
originally in effect. :/
Uh, if we stored the _offset_ that was in effect at the time of storage,
Oh heck no. You NEVER want to use offsets instead of real timezones (something
that far too many programmers don't seem to understand).
it would actually be _worse_ because the new timezone database would not
adjust existing stored values. If we stored the name of the time zone,
I am not sure how that would help us here.
If we stored the name of the timezone then updates to the TZ database would
take effect when the data was read back. Of course that doesn't help with
indexes, but at least you can reindex (and I don't think it'd be to hard to be
more clever than a bulk reindex).
Aside from that, I don't like that we throw away information (namely, what
timezone was used when the record was written). If we stored the timezone you
could actually find that out when you read the data back.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
