-----Original Message----- From: Robbin Kawabata [mailto:Robbin.Kawabata@eng.sun.com] Sent: Friday, September 23, 2005 12:09 PM To: ... Cc: robbin.kawabata@sun.com Subject: tznext 64-bit timezones - Comments Here's some feedback on the 64-bit times proposal dated 6/30/05. 1. New (TZif2) vs. old (TZif) format zoneinfo files and old localtime() To check how an old localtime() would behave with timezones compiled with tznext zic.c, I compared zdump behavior using these combinations: zoneinfo data version of zic localtime() files used to compile version zoneinfo files -------------- ----------------- ----------- a. tzdata2005k zic.c - 2005k 2005k b. tzdata2005k zic.c - tznext 2005k Invoking zdump -v (32-bit) against the timezones for combinations a. vs. b. showed many timezones with behavior differences in the early transitions. For example Africa/Addis_Ababa and US/Pacific: 1,3c1,3 < Africa/Addis_Ababa Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:21:12 1901 AD MT isdst=0 < Africa/Addis_Ababa Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:21:12 1901 AD MT isdst=0 < Africa/Addis_Ababa Mon May 4 21:24:39 1936 UTC = Mon May 4 23:59:59 1936 AD MT isdst=0 ---

Africa/Addis_Ababa Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 23:20:40 1901 LM T isdst=0 Africa/Addis_Ababa Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 23:20:40 1901 LM T isdst=0 Africa/Addis_Ababa Mon May 4 21:24:39 1936 UTC = Mon May 4 23:59:27 1936 LM T isdst=0

1,3c1,3 < US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:45:52 1901 PST isdst= 0 < US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:45:52 1901 PST isdst= 0 < US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst= 0 ---

US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:52:54 1901 LMT isdst= 0 US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:52:54 1901 LMT isdst= 0 US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 02:07:01 1918 LMT isdst= 0

Also note 32-bit vs. 64-bit zdump/localtime() behave differently with the tznext zoneinfo files. (The 64-bit 2005k localtime() behavior seems OK.) /* Problem - 32-bit */ % ./sparc/zdump -v -c 1901,1919 US/Pacific US/Pacific Tue Sep 20 18:27:45 2005 UTC = Tue Sep 20 11:27:45 2005 PDT isdst=1 US/Pacific Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 12:52:54 1901 LMT isdst=0 US/Pacific Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 12:52:54 1901 LMT isdst=0 US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 02:07:01 1918 LMT isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 19:14:07 2038 PST isdst=0 US/Pacific Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 19:14:07 2038 PST isdst=0 /* OK - 64-bit */ % ./sparcv9/zdump -v -c 1901,1919 US/Pacific US/Pacific Tue Sep 20 18:27:24 2005 UTC = Tue Sep 20 11:27:24 2005 PDT isdst=1 US/Pacific -9223372036854775808 = NULL US/Pacific -9223372036854689408 = NULL US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific 9223372036854775807 = NULL US/Pacific 9223372036854689407 = NULL /* OK - 64-bit */ % ./sparcv9/zdump -v -c 1880,1919 US/Pacific US/Pacific Tue Sep 20 18:32:29 2005 UTC = Tue Sep 20 11:32:29 2005 PDT isdst=1 US/Pacific -9223372036854775808 = NULL US/Pacific -9223372036854689408 = NULL US/Pacific Sun Nov 18 19:59:59 1883 UTC = Sun Nov 18 12:07:01 1883 LMT isdst=0 US/Pacific Sun Nov 18 20:00:00 1883 UTC = Sun Nov 18 12:00:00 1883 PST isdst=0 US/Pacific Sun Mar 31 09:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 PST isdst=0 US/Pacific Sun Mar 31 10:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 PDT isdst=1 US/Pacific Sun Oct 27 08:59:59 1918 UTC = Sun Oct 27 01:59:59 1918 PDT isdst=1 US/Pacific Sun Oct 27 09:00:00 1918 UTC = Sun Oct 27 01:00:00 1918 PST isdst=0 US/Pacific 9223372036854775807 = NULL US/Pacific 9223372036854689407 = NULL 2. tznext approach This how I think the tznext approach works. Please correct as needed. a. If the timezone has a POSIX TZ equivalent, then: a1. zic - zic writes 64-bit transitions to the second part of the zoneinfo file (after the second TZif2 header) for times between the lowest year through the highest year specified in the rules for the timezone. If the highest year in the rules is less than 2037, 2037 is used as the highest year. This section can accomodate transitions outside the range of years 1901-2037. a2. localtime() - When a timezone is newly loaded, the POSIX TZ equivalent is used to generate ~400 (more?) years (into the future) worth of transitions into a table (see tzload()->tzparse()). Then localtime() uses the 400-year cycle approach to calculate transitions in the future that are outside the transition table. a3. far past times - zic can exit with "too many transitions" error if the rules define transitions for very early years (eg, "min") which would cause zic to overflow the 1200 entry transition table. Note, none of the timezones in the current timezone source files use "min". An example of rules that could generate this error is the commented-out SystemV rules in the systemv source file. b. If the timezone does not have a POSIX TZ equivalent, then: b1. zic - the 64-bit transition table in the second part of the zoneinfo file (after the second TZif2 header) has transitions for the period from 400 years before the lowest year, through 400 years after the highest year, where the years are specified in the rules for the timezone. This section can accomodate transitions outside the range of years 1901-2037. b2. localtime() - localtime() uses the 400-year cycle approach to calculate times outside the range of the transition table. b3. far past times - zic can handle the "min" keyword for timezones that do not have a POSIX TZ equivalent, because for these timezones, zic creates a 400-year transition table for far past times. 3. zic - "min" keyword Since zic can now issue an error with "min", and since min is described on zic.1 man page, perhaps we should: - Change zic to use a lower bounds year for "min" if it encounters the table overrun condition. zic should issue a warning if this occurs. Document this behavior on the zic man page. or - Just document the limitation with "min" on the zic man page. In the Notes section suggest a workaround to change "min" to a lower year value. 4. zdump It might be nice to add an option to zdump to print out the POSIX TZ equivalent for the timezone.