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@eng.sun.com> To: <tz@lecserver.nci.nih.gov>; <olsona@dc37a.nci.nih.gov> Cc: <Robbin.Kawabata@eng.sun.com> Sent: Tuesday, May 03, 2005 12:52 Subject: RE: Proposed 64-bit changes
From: "Olson, Arthur David (NIH/NCI)" <olsona@dc37a.nci.nih.gov> To: "'Robbin Kawabata'" <Robbin.Kawabata@eng.sun.com>, "Tz (tz@elsie.nci.nih.g ov)" <tz@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