FW: tznext 64-bit timezones - Comments
Olson, Arthur David (NIH/NCI)
olsona at dc37a.nci.nih.gov
Tue Sep 27 16:19:40 UTC 2005
-----Original Message-----
From: Robbin Kawabata [mailto:Robbin.Kawabata at eng.sun.com]
Sent: Friday, September 23, 2005 12:09 PM
To: ...
Cc: robbin.kawabata at 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.
More information about the tz
mailing list