Re: interval madness ...

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Hans-Juergen Schoenig" <postgres(at)cybertec(dot)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: 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