Gregory Stark <stark@enterprisedb.com> writes:
> "Hans-Juergen Schoenig" <postgres@cybertec.at> 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: Updatetimezone code to track the upstream changes since 2003. Inparticular this adds
supportfor 64-bit tzdata files, which isneeded to support DST calculations beyond 2038. Add a regressiontest case to
givesome 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
