On Sat, Oct 4, 2014 at 05:03:24PM -0400, Tom Lane wrote:
> Bruce Momjian <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
