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
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq