On Sat, Oct 4, 2014 at 05:03:24PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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+00SELECT'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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
