Gregory Stark <[EMAIL PROTECTED]> writes: > "Hans-Juergen Schoenig" <[EMAIL PROTECTED]> writes: >> why do i get a different timezone just because of adding one more century? >> i cannot see an obvious reason.
> This thread may be enlightening: > http://archives.postgresql.org/pgsql-patches/2007-09/msg00292.php > I can't find the message for the later commits but they weren't > backpatched to 8.3 so unless you're using HEAD you won't get properly > working timezones for post-2038 Yeah, that patch did get in earlier this year: 2008-02-16 16:16 tgl * src/: test/regress/expected/timestamptz.out, test/regress/sql/timestamptz.sql, timezone/README, timezone/ialloc.c, timezone/localtime.c, timezone/pgtz.c, timezone/pgtz.h, timezone/private.h, timezone/scheck.c, timezone/strftime.c, timezone/tzfile.h, timezone/zic.c: Update timezone code to track the upstream changes since 2003. In particular this adds support for 64-bit tzdata files, which is needed to support DST calculations beyond 2038. Add a regression test case to give some minimal confidence that that really works. Heikki Linnakangas I believe the behavior now is that the code will assume the last known DST rule for a zone applies indefinitely far into the future. But in 8.3 and before all times past 2038 are taken as local standard time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
