Skip site navigation (1) Skip section navigation (2)

Re: tzcode update

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: tzcode update
Date: 2008-02-12 16:09:38
Message-ID: 47B1C4C2.2010103@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
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

In response to

Responses

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2008-02-13 10:51:07
Subject: Re: tzcode update
Previous:From: Tom LaneDate: 2008-02-11 21:32:48
Subject: Re: Proposed patch for 8.3 VACUUM FULL crash

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group