- tz - lists.iana.org

Re: timezone magic number
by Valery Aronov April 27, 1995

April 27, 1995

Daniel Quillan wrote: > I have one comment regarding the timezone file format. > > Why not use a few of 20 remaining bytes in tzh_reserved field for a > magic number that would be unique to timezone data files? 4 bytes at > the beginning of the file would be great, but if you're concerned > about space then 2 bytes would do the job if selected carefully. I would like to add that we need it to be PERSISTENT: even if timezone would not exist anymore its magic number should be preserved. It makes possible to use them for database storage. Valery -- Valery Aronov ,-_;\ Telstra Australia ph (61-2) 395 33 59 / \ Telecom Plaza fax (61-2) 395 32 25 \_,-._* <-- 320 Pitt Street valery(a)ind.tansu.com.au v Sydney South NSW 2000 Australia

1 0

timezone magic number
by quinlan＠yggdrasil.com April 27, 1995

April 27, 1995

I have one comment regarding the timezone file format. Why not use a few of 20 remaining bytes in tzh_reserved field for a magic number that would be unique to timezone data files? 4 bytes at the beginning of the file would be great, but if you're concerned about space then 2 bytes would do the job if selected carefully. Thanks. Dan -- Daniel Quinlan Member of the League for Programming Freedom quinlan(a)yggdrasil.com

1 0

Japan to use DST. Indiana changed? Changes for Israel, W-SU, etc.
by eggert＠twinsun.com April 4, 1995

April 4, 1995

The big news is that Japan will most likely start using daylight saving next year. It isn't confirmed yet, but it seems probable. See below for details. A lot of software in Japan will have to be rewritten, since they haven't used daylight saving since the dawn of the computer era. This looks like a growth opportunity for tz.... Also, while I was in Japan last month I read a newspaper article talking about daylight saving; it mentioned something about the Indiana legislature changing the time zone rules again in the last few weeks. No details. Anybody else heard anything about this rumor? Other than that, here are proposed changes to the current tz rules: Proposed changes that affect behavior: * Ephraim Silverberg's correction for this autumn's transition in Israel. * Make `W-SU' a link to Europe/Moscow instead of something with ???? in it. Proposed comment and/or cleanup changes: * Remove unused GB-Eire rules starting in 1996, and comment on the relationship between GB-Eire and EC. * Comments about the proposed daylight saving time in Japan in 1996. * Comments about DST in Japan between 1948 and 1951. * Comment Serbia/Yugoslavia's name more accurately. PS. I'll be on vacation starting Thursday so won't answer mail for a while. =================================================================== RCS file: RCS/asia,v retrieving revision 1994.8 retrieving revision 1994.8.1.1 diff -c -r1994.8 -r1994.8.1.1 *** asia 1994/12/10 16:26:05 1994.8 --- asia 1995/04/04 18:04:39 1994.8.1.1 *************** *** 48,54 **** # 8:00 PST PDT Philippines* # 8:00 SGT Singapore # 8:00 UST UDT Ulan Bator* ! # 9:00 JST Japan # 9:00 KST KDT Korea # 9:00 MLT Moluccas* # 9:30 CST Australian Central Standard Time --- 48,54 ---- # 8:00 PST PDT Philippines* # 8:00 SGT Singapore # 8:00 UST UDT Ulan Bator* ! # 9:00 JST JDT Japan # 9:00 KST KDT Korea # 9:00 MLT Moluccas* # 9:30 CST Australian Central Standard Time *************** *** 461,467 **** Rule Zion 1994 only - Apr 1 0:00 1:00 D Rule Zion 1994 only - Aug 28 0:00 0:00 S Rule Zion 1995 only - Mar 31 0:00 1:00 D ! Rule Zion 1995 only - Aug 27 0:00 0:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 --- 461,474 ---- Rule Zion 1994 only - Apr 1 0:00 1:00 D Rule Zion 1994 only - Aug 28 0:00 0:00 S Rule Zion 1995 only - Mar 31 0:00 1:00 D ! # On 1995-03-13 Ephraim Silverberg corrected the next line from Aug 27 to Sep 3. ! Rule Zion 1995 only - Sep 3 0:00 0:00 S ! ! # From Ephraim Silverberg (1995-03-13): ! # The Spokeswoman's office confirmed that there are not yet any dates ! # for the timezone conversion for the years 1996 and beyond yet ! # and this is one of the things the newly-appointed Minister of Interior ! # will have to decide sometime this year. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 *************** *** 475,494 **** # `9:00' and `JST' is from Guy Harris. ! # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): ! # Shanks says that the far southern Ryukyu Is (Nansei-Shoto) are 8:00, ! # but we don't have a good location name for them; ! # we don't even know the name of the principal town. ! # There is no information for Marcus. ! # Other Japanese possessions are probably like Asia/Tokyo. # From Shanks (1991): # Japan switched from the Japanese calendar on 1893 Jan 1. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tokyo 9:19:04 - LMT 1896 9:00 - JST #Zone Asia/South_Ryukyu 8:14:44 - LMT 1896 # Amitori # 8:00 - CST # Jordan # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): --- 482,525 ---- # `9:00' and `JST' is from Guy Harris. ! # From Paul Eggert <eggert(a)twinsun.com> (1995-03-06): ! # Today's _Asahi Evening News_ (page 4) reports that Japan had ! # daylight saving between 1948 and 1951, but ``the system was discontinued ! # because the public believed it would lead to longer working hours.'' ! # Shanks writes that daylight saving in Japan during those years was as follows: ! # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! #Rule Japan 1948 only - May Sun>=1 2:00 1:00 D ! #Rule Japan 1948 1951 - Sep Sat>=8 2:00 0 S ! #Rule Japan 1949 only - Apr Sun>=1 2:00 1:00 D ! #Rule Japan 1950 1951 - May Sun>=1 2:00 1:00 D ! # but the only locations using it were US military bases. ! # We go with Shanks and omit daylight saving in those years for Asia/Tokyo. ! # ! # The same news article also reports that Japan is likely to go on DST in 1996 ! # as follows, where I've guessed the AT and LETTER/S columns: ! # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S ! #Rule Japan 1996 max - Apr Sun>=1 2:00 1:00 D ! #Rule Japan 1996 max - Oct lastSun 2:00 0 S # From Shanks (1991): # Japan switched from the Japanese calendar on 1893 Jan 1. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tokyo 9:19:04 - LMT 1896 9:00 - JST + # If Japan adopts DST in 1996, replace the above line with the following lines: + # 9:00 - JST 1996 + # 9:00 Japan J%sT + # and uncomment the two `Rule' lines commented out above. + + # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): + # Shanks says that the far southern Ryukyu Is (Nansei-Shoto) are 8:00, + # but we don't have a good location name for them; + # we don't even know the name of the principal town. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] #Zone Asia/South_Ryukyu 8:14:44 - LMT 1896 # Amitori # 8:00 - CST + # There is no information for Marcus. + # Other Japanese possessions are probably like Asia/Tokyo. # Jordan # From Paul Eggert <eggert(a)twinsun.com> (November 18, 1993): =================================================================== RCS file: RCS/backward,v retrieving revision 1995.2 retrieving revision 1995.2.1.1 diff -c -r1995.2 -r1995.2.1.1 *** backward 1995/02/21 15:43:22 1995.2 --- backward 1995/03/23 01:42:23 1995.2.1.1 *************** *** 73,76 **** --- 73,77 ---- Link Pacific/Samoa US/Samoa Link Etc/UTC UTC Link Etc/Universal Universal + Link Europe/Moscow W-SU Link Etc/Zulu Zulu =================================================================== RCS file: RCS/europe,v retrieving revision 1995.2 retrieving revision 1995.2.1.1 diff -c -r1995.2 -r1995.2.1.1 *** europe 1995/02/21 15:43:19 1995.2 --- europe 1995/04/04 10:39:24 1995.2.1.1 *************** *** 714,724 **** Rule GB-Eire 1971 only - Oct 31 3:00 0 GMT Rule GB-Eire 1972 1980 - Oct Sun>=23 2:00s 0 GMT # 1981 on ! Rule GB-Eire 1981 max - Mar lastSun 1:00u 1:00 BST Rule GB-Eire 1981 1989 - Oct Sun>=23 1:00u 0 GMT Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00u 0 GMT ! Rule GB-Eire 1996 max - Oct lastSun 1:00u 0 GMT ! # Also see EC, which (starting 1996) differs only in LETTER/S. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Sep 22 --- 714,723 ---- Rule GB-Eire 1971 only - Oct 31 3:00 0 GMT Rule GB-Eire 1972 1980 - Oct Sun>=23 2:00s 0 GMT # 1981 on ! Rule GB-Eire 1981 1995 - Mar lastSun 1:00u 1:00 BST Rule GB-Eire 1981 1989 - Oct Sun>=23 1:00u 0 GMT Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00u 0 GMT ! # See EC for rules starting in 1996. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Sep 22 *************** *** 760,766 **** Rule EC 1979 1995 - Sep lastSun 1:00u 0 - Rule EC 1981 max - Mar lastSun 1:00u 1:00 " DST" Rule EC 1996 max - Oct lastSun 1:00u 0 - - # Also see GB-Eire, which (starting 1996) differs only in LETTER/S. # W-Eur differs from EC only in that W-Eur uses standard time. Rule W-Eur 1800 only - Jan 1 0:00 0 - --- 759,764 ---- *************** *** 824,830 **** Zone WET 0:00 EC WET%s Zone MET 1:00 M-Eur MET%s Zone EET 2:00 EC EET%s - Zone W-SU 3:00 M-Eur ???? # Tom Hoffman says that MET is also known as Central European Time --- 822,827 ---- *************** *** 1789,1795 **** 12:00 - ASK 1992 Jan 19 2:00s 13:00 Russia AS%s ! # Serbia # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Belgrade 1:22:00 - LMT 1884 --- 1786,1792 ---- 12:00 - ASK 1992 Jan 19 2:00s 13:00 Russia AS%s ! # Yugoslavia (what's left of it -- mostly Serbia) # They switched from the Julian to the Gregorian calendar on 1918 Mar 18. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Belgrade 1:22:00 - LMT 1884

2 1

tzcode95c.tar.gz
by ado March 13, 1995

March 13, 1995

tzcode95c.tar.gz includes the one-line fix for sign extension problems in detzcode; it is available from elsie.nci.nih.gov by anonymous ftp. --ado

1 0

tzcode95b.tar.gz and tzdata95b.tar.gz
by ado March 11, 1995

March 11, 1995

The files tzcode95b.tar.gz and tzdata95b.tar.gz are now available by anonymous ftp from elsie.nci.nih.gov. Minor changes in both: the "code" file contains a workaround for the lack of "unistd.h" in Microsoft C++ version 7; the "data" file contains a fixed "Link" for America/Shiprock. --ado

2 1

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 11, 1995

March 11, 1995

>Gawd - Chris, really, wouldn't just [perfectly simple portable code] >work rather more easily ... Yep, but I am not embarrassed ... as I said, it is these soma pills that are doing this to me. :-) (Seriously, this `muscle relaxant' seems to let one's mind leak out the ears. They do help out with the muscle spasm, but they make it like trying to program while drunk out of one's mind...) Chris

1 0

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 11, 1995

March 11, 1995

>However, not all operating systems have [int32_t] ... Probably a case >for #ifdef'ing the code. Hm, good point, I was thinking of BSD systems specifically. (It is these `soma' muscle relaxant pills! I swear! :-) ) If one is to resort to #ifdef's, the original suggestion of testing the top bit and OR'ing in ~0L << 32 should work, using something like: #if LONG_MAX > 2147483647 /* long > 32 bits */ if (result & (1L << 31)) result |= ~0L << 32; #endif return (result); The (long)(int32_t) method may produce better code on an Alpha, Chris

2 1

Re: problem with detzcode on machines w/64 bit longs
by Chris Torek March 10, 1995

March 10, 1995

>How about ... (result >> 31) ? (result | (~0L << 32)) : result The minimum number of bits in a `long' is 32 (LONG_MIN and LONG_MAX must be at most -2147483647 and +2147483647 respectively; the former allows for ones-complement). The result of a shift operator is defined if and only if the shift count does not equal or exceed the number of bits in the type. Thus, on a machine with 32-bit ints, `~0L << 32' is undefined. More practically, on (say) a VAX, the shift instruction only looks at the low 5 bits of the shift count, so ~0L << 32 will be ~0L => -1. Since there is now a new ugly set of `intNN_t' typedefs in <machine/types.h>, your best bet is probably: return (time_t)(int32_t)result; Chris

2 1

Re: problem with detzcode on machines w/64 bit longs
by Tom Peterson March 10, 1995

March 10, 1995

>> yeah, that should work as desired, though i forget if "0L" is an >> ansi-C-ism, and don't have a book around to check... > >Yep, it's in there. Section 3.1.3.2 of the spec I have dated 1990. >I think this has been around for a while, probably in K&R too. Just checked & it's definitely in K&R too. Appendix A section 2.4.2. - Tom

1 0

Re: problem with detzcode on machines w/64 bit longs
by Bradley White March 10, 1995

March 10, 1995

> Chris Demetriou, who maintains the NetBSD DEC Alpha port, reported a > problem in localtime.c's detzcode() function that occurs because the > value being extracted from the string in that function is not sign > extended properly. > > He says: > The problem is that if you do what the current version does, > then you can end up with numbers like 0xffffyyyy being > returned from detzcode(), i.e. no sign extension into the > upper 32 bits of the long. Because of this, among other > things, 'date' will say that it's some time in the year > 2025... > > Using the following detzcode() implementation (which unrolls the loop > and doesn't mask the first character) works, but it suffers from a > small defect in that it assumes signed characters. > > static long > detzcode(codep) > const char * const codep; > { > register long result; > > result = (codep[0] << 24) \ > | (codep[1] & 0xff) << 16 \ > | (codep[2] & 0xff) << 8 > | (codep[3] & 0xff); > return result; > } > > casting codep[0] to signed char would fix that, but would require a > ANSI compiler. How about this simple change? *** tz95b/localtime.c Sat Mar 4 11:22:26 1995 --- localtime.c Fri Mar 10 08:51:53 1995 *************** *** 186,200 **** static long detzcode(codep) const char * const codep; { register long result; register int i; ! result = 0; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void settzname P((void)) --- 186,200 ---- static long detzcode(codep) const char * const codep; { register long result; register int i; ! result = ~0; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; } static void settzname P((void))

3 4