Re: interval madness ...

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