Proposed 64-bit changes

Mark Davis mark.davis at
Fri Apr 29 21:41:53 UTC 2005

For #1, that's exactly what we do in ICU, since we have to convert all times
covered by the Java Date. So we generate extra information for the rules
covering the last year, that we apply algorithmically into the indefinite
future. We would strongly support adding the ability to generate that data
to zic, and could contribute some code for doing it.


----- Original Message ----- 
From: "Robbin Kawabata" <Robbin.Kawabata at>
To: <olsona at>; <tz at>
Cc: <robbin.kawabata at>
Sent: Friday, April 29, 2005 13:59
Subject: Re: Proposed 64-bit changes

> Some feedback -
> 1.  This is another idea for supporting dates into the far future.
> Is it feasible for zic to encode variable information in the data file
> for the last set of rules, that would be used for times past the last
> entry in the transition table?  Then localtime() would use the variables
> algorithmically rather than using table-driven data, for dates past the
> last table entry.  Perhaps set a minimum size for the table entries
> (ie, have table entries at least up to year xxxx.)
> zic would effectively map the last set of transition rules of an Olson
> timezone to an equivalent POSIX timezone.
> 2.  I'm not sure yet, but with 9x larger timezone binaries, Sun might
> retain the old-style timezone binaries for timezone patch updates.
> If so, it might be useful if zic has an option to produce old-style
> binaries.
> 3.  POSIX timezone 64-bit time_t support
> It seems the new localtime.c does not support 64-bit dates for POSIX
> timezones.  Will this be supported?
> Thanks,
> Robbin
> > Date: Thu, 21 Apr 2005 15:24:10 -0400 (EDT)
> > From: Arthur David Olson <olsona at>
> > To: tz at
> > Subject: Proposed 64-bit changes
> >
> > Below are diffs to the time zone code to cope with 64-bit time_t
> > these reflect suggestions I've received to date. Absent negative
> > I'll update the ftp versions on May 2, 2005.

More information about the tz mailing list