Re: Aussie timezone database changes incoming

On Sat, Oct 4, 2014 at 05:03:24PM -0400, Tom Lane wrote:
> 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.

I see:

SET timezone = 'GMT';

SELECT '1901-01-01 00:00:00 EDT'::timestamptz;
timestamptz
------------------------
1901-01-01 04:00:00+00

SELECT '1901-01-01 00:00:00 EST'::timestamptz;
timestamptz
------------------------
1901-01-01 05:00:00+00

This is returning adjustements for EDT in a year when there was not
daylight savings time.

How are Russians supposed to deploy Postgres on October 26 if they use
abbeviations? At midnight?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +