From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Andrew McNamara <andrewm(at)object-craft(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Aussie timezone database changes incoming |
Date: | 2014-10-04 21:03:24 |
Message-ID: | 20714.1412456604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Sat, Oct 4, 2014 at 02:21:24PM -0400, Tom Lane 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.
Well, the other side of that coin is that those new abbreviation values
aren't valid *yet*.
It's becoming clear to me that our existing design whereby zone
abbreviations represent fixed GMT offsets isn't really good enough.
I've been wondering whether we could change things so that, for instance,
"EDT" means "daylight time according to America/New_York" and the system
would consult the zic database to find out what the prevailing GMT offset
was in that zone on that date. This would be a lot more robust in the
face of the kind of foolishness we now see actually goes on.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-10-04 21:25:45 | Re: Aussie timezone database changes incoming |
Previous Message | Bruce Momjian | 2014-10-04 20:25:15 | Re: Aussie timezone database changes incoming |