We included the public domain timezone library by Arthur David Olson
back in 2004 into our source tree, but we haven't kept it up to date
with the upstream changes since.
We've made a number of small changes to our version of the library,
including:
- formatting changes, mostly thanks to pgindent
- widened time_t to 8 bytes
- we only include the parts of the library that we need
which means that we can't just take the new library version and drop it
in the src/timezone directory. We can debate whether those changes were
a good idea or not, given that they make the merging harder, but my take
is that it's not that bad given how seldom and little the upstream code
changes.
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.
The main difference between those version seems to be support for 64-bit
time_t, including
- extended data file format, with 64-bit time values
- extrapolation of DST transitions in a 400 year cycle, for values
not directly covered by the transition table.
In addition to that, they've added "public domain" notice to the top of
ialloc.c, and some other cosmetic changes. We already had such a notice
in our version of the file, but the original did not.
I merged the upstream changes, mostly manually, trying to be faithful to
the original diff to make future merges easier. But I also made some
whitespace/comment changes, like we've done before to our version of the
code: no double-stars in comments, braces on lines of their own.
Attached is the resulting patch against Postgres CVS HEAD.
In addition to manually merging the patch, I had to teach
pg_next_dst_boundary how to extrapolate the DST transitions. The code
there is copy-pasted from localsub, so I copy-pasted that change from
there as well. Also, they now use a binary search instead of linear
search in localsub, and I copied that change to pg_next_dst_bounday as
well (that is why I started looking at this in the first place,
http://archives.postgresql.org/pgsql-patches/2007-09/msg00291.php)
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?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
