Re: tzcode update
От | Heikki Linnakangas |
---|---|
Тема | Re: tzcode update |
Дата | |
Msg-id | 47B1C4C2.2010103@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: tzcode update (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: tzcode update
("Heikki Linnakangas" <heikki@enterprisedb.com>)
|
Список | pgsql-patches |
Tom Lane wrote: > "Heikki Linnakangas" <heikki@enterprisedb.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
В списке pgsql-patches по дате отправления: