Proposed 64-bit changes

[Robbin Kawabata]

> From: "Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov>
> To: "'Robbin Kawabata'" <Robbin.Kawabata at eng.sun.com>, "Tz (tz at elsie.nci.nih.g
ov)" <tz at elsie.nci.nih.gov>
> Subject: RE: Proposed 64-bit changes
> Date: Mon, 2 May 2005 09:46:29 -0400
>
> > 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.)
>
> This approach isn't as general as the extend-400-years approach. Take, for
> example, the proposal a few years back to extend DST into November in the
> Pacific Time Zone in presidential election years (as a way of minimizing
> announced results from New York affecting voting in California). The
> irregularities that would have resulted can't be handled by a POSIX-style
> rule string; they can be handled by the extend-400-years approach.

To address these types of timezones, zic could write a second set of
variables.  One set of variables would be used (for example) for nonpres
years, and one set of variables would be used for uspres years.

As a side note, our standards representative comments that POSIX TZ rules
have been extended in recent years to be more flexible than they had been
in the past, and would likely be extended again if uspres, even, odd,
or other rules are actually put into practice.

After more discussion here, we feel the extend-400-year approach would 
be acceptable.  We would be OK with either the extend-400-year approach 
or the variable approach.

Robbin