Proposed 64-bit changes

[Mark Davis]

I'm a bit lost on what exactly the alternatives being discussed are. Ill try
to set them out.

A. Extend by last year.
We have to have format *something* for the entire range of time covered by
our datatypes
(http://icu.sourceforge.net/userguide/universalTimeScale.html). What we do
is take whatever binary comes out of zic, and apply the last year's rules to
each year after that. They are applied algorithmically so the dates may
shift year by year. We don't try to do anything like even/odd years, because
we don't see a good way to do that.

B. No Daylight
Just use the standard offset; turn off daylight. This would be simpler, of
course, but seems like it would be somewhat less likely to be correct.

C. Others?
If there is a way to do something smarter than A, we'd definitely like to
hear it.

‎Mark

----- Original Message ----- 
From: "Robbin Kawabata" <Robbin.Kawabata at eng.sun.com>
To: <tz at lecserver.nci.nih.gov>; <olsona at dc37a.nci.nih.gov>
Cc: <Robbin.Kawabata at eng.sun.com>
Sent: Tuesday, May 03, 2005 12:52
Subject: RE: Proposed 64-bit changes


> > 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
>
>
>