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
tounderstand).
> 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
coursethat 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
thana 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.