Re: tzcode update

Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> I was not able to find anything like release notes that would list the
>> differences between tzcode2003e, which I believe is the version that we
>> included back then, and the latest version tzcode2007k. So I just took a
>> diff between those, and deduced from there what has changed.
>
> Oh good, this has been on my to-do list for awhile ... but I'm happy
> to let you do it ;-)
>
>> I don't really know how to test this. It passes the regression tests,
>> after the fixes to pg_dst_next_boundary, but I was expecting there to be
>> some failures now that we support timezones for timestamps outside the
>> 32-bit time_t range. Apparently our tests don't cover that?
>
> Unless the 64-bit extension changed the semantics a lot more than I
> think, any given compiled tzdata file covers only a finite range of
> years. The extension makes it *possible* for the data to extend outside
> the time_t range, but you won't actually see a difference in behavior
> unless (a) you do extend the range (what's zic's default now?) and
> (b) you test a date falling within the extended range. So I'm not
> too surprised that there are no cases in the regression tests that
> notice. We should probably add some reaching out to 2100 or so.

zic does extend the range by default now, as witnessed by:

postgres=# set timezone = 'Europe/London';
SET
postgres=# SELECT '2090-07-01 15:00:00'::timestamptz;
timestamptz
------------------------
2090-07-01 15:00:00+01
(1 row)

Their new format is best described by this mail by Arhur David Olson
(the author of the library):

http://article.gmane.org/gmane.comp.time.tz/474/match=64+bit

> The name of the game would be to produce binary files with:
> 1. data with 32-bit time values through 2037 (for use by old
> systems)
> 2. data with 64-bit time values for "historic" years
> 3. a newline enclosed, POSIX-conforming
> TZ-environment-variable-style string
> telling what to do in years beyond those covered by 2 above.
>
> There are a few places (Cairo, Godthab, Chile) that can't be represented by
> POSIX-conforming strings; for these we'd punt to the "write 400 years worth
> of data and work modulo 400" approach (leaving off the trailing TZ string).

I'll add some tests to cover timestamps > 2038.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com