Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
