- tz - lists.iana.org

Zdump for Warsaw 1944
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

I confirmed today at work on a Linux server that there is a problem similar to Asia/Baku, for timezone Europe/Warsaw in 1944. This is a fraction of the output produced for timezone Europe/Warsaw using JodaTime: UTC: 1944-04-03T00:59:59.000Z, Europe/Warsaw: 1944-04-03T01:59:59.000+01:00 UTC: 1944-04-03T01:00:00.000Z, Europe/Warsaw: 1944-04-03T03:00:00.000+02:00 UTC: 1944-09-30T21:59:59.000Z, Europe/Warsaw: 1944-09-30T23:59:59.000+02:00 UTC: 1944-09-30T22:00:00.000Z, Europe/Warsaw: 1944-09-30T23:00:00.000+01:00 The equivalent in zdump should be something like: Europe/Warsaw Mon Apr 3 00:59:59 1944 UTC = Mon Apr 3 01:59:59 1944 CET isdst=0 Europe/Warsaw Mon Apr 3 01:00:00 1944 UTC = Mon Apr 3 03:00:00 1944 CEST isdst=1 Europe/Warsaw Sat Sep 30 21:59:59 1944 UTC = Sat Sep 30 23:59:59 1944 CEST isdst=1 Europe/Warsaw Sat Sep 30 22:00:00 1944 UTC = Sat Sep 30 23:00:00 1944 CET isdst=0 The error is the change from DST to standard time in 1944. It should have been October 4.th. at 2:00 and not at the exact time that there is a change rule from C-Eur to Poland, which *is* the October 1.st 1944 at 0:00, but this should not result in a change in GMT offset from +2 to +1. Here is the relevant lines from the tz database source, I'm suggesting to add a line for DST for Poland rule before 1.st. October and copied a line from the C-Eur rule for convenience, but there must be many ways to do this: Rule C-Eur 1944 only - Apr 3 2:00s 1:00 S # Whitman gives 1944 Oct 7; go with Shanks. Rule C-Eur 1944 only - Oct 2 2:00s 0 - # Poland # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Poland 1918 1919 - Sep 16 2:00s 0 - Rule Poland 1919 only - Apr 15 2:00s 1:00 S +Rule Poland 1944 only - Apr 3 2:00s 1:00 S # Whitman gives 1944 Nov 30; go with Shanks. Rule Poland 1944 only - Oct 4 2:00 0 - # For 1944-1948 Whitman gives the previous day; go with Shanks. Rule Poland 1945 only - Apr 29 0:00 1:00 S Rule Poland 1945 only - Nov 1 0:00 0 - This should produce the following zdump output: Europe/Warsaw Mon Apr 3 00:59:59 1944 UTC = Mon Apr 3 01:59:59 1944 CET isdst=0 Europe/Warsaw Mon Apr 3 01:00:00 1944 UTC = Mon Apr 3 03:00:00 1944 CEST isdst=1 Europe/Warsaw Tue Oct 3 23:59:59 1944 UTC = Wed Oct 4 01:59:59 1944 CEST isdst=1 Europe/Warsaw Wed Oct 4 00:00:00 1944 UTC = Wed Oct 4 01:00:00 1944 CET isdst=0 Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.worldtimeexplorer.com/index.html

2 1

EUAsia rule glitch?
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

I have found an application of the rule EUAsia for Azerbaijan, which results in DST for Azerbaijan since 01-Jan-1996 which doesn't seem logical, and does not follow common sense. I don't have a version of zdump here, but use JodaTime, a package that uses tz database directly to produce the tz transitions. Jodatime reports the following transitions for Baku for 1996: UTC: 1995-12-31T19:59:59.000Z, Asia/Baku: 1995-12-31T23:59:59.000+04:00 UTC: 1995-12-31T20:00:00.000Z, Asia/Baku: 1996-01-01T01:00:00.000+05:00 UTC: 1996-10-27T00:59:59.000Z, Asia/Baku: 1996-10-27T05:59:59.000+05:00 UTC: 1996-10-27T01:00:00.000Z, Asia/Baku: 1996-10-27T05:00:00.000+04:00 This is based on the following tz database definition: Zone Asia/Baku 3:19:24 - LMT 1924 May 2 3:00 - BAKT 1957 Mar # Baku Time 4:00 RussiaAsia BAK%sT 1991 Mar 31 2:00s 3:00 1:00 BAKST 1991 Aug 30 # independence 3:00 RussiaAsia AZ%sT 1992 Sep lastSat 23:00 4:00 - AZT 1996 # Azerbaijan time 4:00 EUAsia AZ%sT 1997 4:00 Azer AZ%sT The EUAsia rule looks like this: # These rules are stolen from the `europe' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - As you can see above, the intention was simply to copy EU rules to the 'asia' file so as to use the same logic (because the asia file can't see the europe file). However, the above implementation is a cut-down version of EU rule, where the logic is presumably that we only need rules for 1996 and beyond. This has the side effect that DST in the EUAsia rule is applied Last Sunday of March 1981 and maintained unaltered until Last Sunday of October 1996. The error is that DST was (probably) not observed from 01-Jan-1996 to Last Sunday of March 1996, although I don't have authoritative information about this. I therefore suggest the following change: # These rules are stolen from the `europe' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S +Rule EUAsia 1979 1995 - Sep lastSun 1:00u 0 - Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - This will give EUAsia rule the expected behavior right from 1981, with DST transitions equivalent to the EU rule. Regards, Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Uzbekistan doubled lines
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

# Uzbekistan # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Samarkand 4:27:12 - LMT 1924 May 2 4:00 - SAMT 1930 Jun 21 # Samarkand Time 5:00 - SAMT 1981 Apr 1 5:00 1:00 SAMST 1981 Oct 1 6:00 RussiaAsia TAS%sT 1991 Mar 31 2:00 # Tashkent Time 5:00 RussiaAsia TAS%sT 1991 Sep 1 # independence - 5:00 RussiaAsia UZ%sT 1992 5:00 RussiaAsia UZ%sT 1993 5:00 - UZT Zone Asia/Tashkent 4:37:12 - LMT 1924 May 2 5:00 - TAST 1930 Jun 21 # Tashkent Time 6:00 RussiaAsia TAS%sT 1991 Mar 31 2:00s 5:00 RussiaAsia TAS%sT 1991 Sep 1 # independence - 5:00 RussiaAsia UZ%sT 1992 5:00 RussiaAsia UZ%sT 1993 5:00 - UZT In the above timezones it seems that the 1992-lines are superfluous and are handled nicely by the 1993-lines. Is there something I'm missing here? - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Uruguay rule
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

In the Uruguay rule, for 1941 there seems to be an obsolete statement Rule Uruguay 1937 1941 - Mar lastSun 0:00 0 - # Whitman gives 1937 Oct 3; go with Shanks. Rule Uruguay 1937 1940 - Oct lastSun 0:00 0:30 HS # Whitman gives 1941 Oct 24 - 1942 Mar 27, 1942 Dec 14 - 1943 Apr 13, # and 1943 Apr 13 ``to present time''; go with Shanks. Rule Uruguay 1941 only - Aug 1 0:00 0 - Rule Uruguay 1942 only - Jan 1 0:00 0:30 HS The next-last line above concerning 1941-08-01 can be deleted, since Last Sunday of March 1941 was returning to standard time, no need to do it again. Regards, - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

Martin County, Indiana defects back to eastern time
by Paul Eggert March 21, 2006

March 21, 2006

An InsideINdianaBusiness.com report on Martin county, Indiana <http://www.insideindianabusiness.com/newsitem.asp?ID=17202> (2006-03-15) say that the county commissioners have voted to stay on eastern time in 2006, which means they will stay like America/Indiana/Indianopolis, instead of switching to eastern time as earlier planned. They join Pulaski county in changing their minds. (I reported on this last month.) Those Hoosiers! Such a flighty and changeable people!

1 0

Capital of Montserrat
by Jesper Norgaard Welen March 21, 2006

March 21, 2006

Some time ago I investigated what might be the capital of Montserrat when the former capital Plymouth was abandoned because of heavy volcanic activity in 1995 and onwards (now it is a bit more quiet). I came to the conclusion that it was probably Brades, from having several addresses of government there. Recently I checked wikipedia and the CIA factbook and it confirms it was changed from Plymouth to Brades. In the tz database we don't have a big problem from the fortunate timezone naming America/Montserrat instead of America/Olveston. However, there are two comments that state it is Olveston in the tz entry (see below). In the web I could only find an old reference from 1996 talking about a government office in Olveston, other references say Brades or Brades Estate. # Montserrat # From Paul Eggert (1997-08-31): # Recent volcanic eruptions have forced evacuation of Plymouth, the capital. # Luckily, Olveston, the current de facto capital, has the same longitude. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Olveston -4:00 - AST http://www.gis.gov.ms/ http://www.odci.gov/cia/publications/factbook/geos/mh.html http://en.wikipedia.org/wiki/Montserrat http://en.wikipedia.org/wiki/Brades%2C_Montserrat Unfortunately that will mean we have to recalculate LMT since it is (as would be expected) not very close to the turmoil of Plymouth. The last page has a nice little map to show where Brades is located in the north of Montserrat. As usual tz database prefers largest city, but I don't know if that differs from Brades. - Jesper Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (55) 58-04-20-04 ext. 1374 Fax: +52 (55) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

2 1

RE: tz behavior difference TZif vs. TZif2
by Olson, Arthur David (NIH/NCI) [E] March 20, 2006

March 20, 2006

Here's what I get from "od" on elsie: > Script started on Mon 20 Mar 2006 08:53:11 AM EST > elsie$ od -xc ./tmp/etc/zoneinfo/Indian/Cocos > 0000000 545a 6966 3200 0000 0000 0000 0000 0000 > T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000020 0000 0000 0000 0001 0000 0001 0000 0000 > \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 > 0000040 0000 0000 0000 0001 0000 0008 0000 5b68 > \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 [ h > 0000060 0004 4c4d 5400 4343 5400 0000 545a 6966 > \0 004 L M T \0 C C T \0 \0 \0 T Z i f > 0000100 3200 0000 0000 0000 0000 0000 0000 0000 > 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > 0000120 0000 0002 0000 0002 0000 0000 0000 0001 > \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 > 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 > \0 \0 \0 002 \0 \0 \0 \b ÿ ÿ ÿ ÿ | U & ¤ > 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 > 001 \0 \0 Z Ü \0 \0 \0 \0 [ h \0 004 L M T > 0000200 0043 4354 0000 0000 000a 4343 542d 363a > \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : > 0000220 3330 0a00 > 3 0 \n > 0000223 > elsie$ exit > > script done on Mon 20 Mar 2006 08:53:26 AM EST Note the "0000060 0004" above and the "0000060 0000" below. The number in question is the index into the zone abbreviation characters which are "LMT\0CCT\0"; the difference is why we're seeing "CCT" (the correct behavior) on elsie and "LMT" (the worng behavior) on your system; it's also why the zgress test worked here on elsie. --ado -----Original Message----- From: Robbin Kawabata [mailto:Robbin.Kawabata@eng.sun.com] Sent: Friday, March 17, 2006 5:11 PM To: tz(a)elsie.nci.nih.gov; eggert(a)CS.UCLA.EDU; Olson, Arthur David (NIH/NCI) [E]; olsona(a)elsie.nci.nih.gov Cc: robbin.kawabata(a)sun.com Subject: tz behavior difference TZif vs. TZif2 ... This is a dump of the Indian/Cocos TZif2 file: % od -xc ./Indian/Cocos 0000000 545a 6966 3200 0000 0000 0000 0000 0000 T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0008 0000 5adc \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 Z 334 0000060 0000 4c4d 5400 4343 5400 0000 545a 6966 \0 \0 L M T \0 C C T \0 \0 \0 T Z i f 0000100 3200 0000 0000 0000 0000 0000 0000 0000 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000120 0000 0002 0000 0002 0000 0000 0000 0001 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 \0 \0 \0 002 \0 \0 \0 \b 377 377 377 377 | U & 244 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 001 \0 \0 Z 334 \0 \0 \0 \0 [ h \0 004 L M T 0000200 0043 4354 0000 0000 000a 4343 542d 363a \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : 0000220 3330 0a00 3 0 \n 0000223 ...

1 0

tz behavior difference TZif vs. TZif2
by Robbin Kawabata March 19, 2006

March 19, 2006

I still see a behavior difference for some timezones with 32-bit 2005l localtime() when using TZif vs. TZif2 (built with 2006b zic.c) format timezones. Do you get this behavior too? I would have expected the difference to show up on a zgress test, however. It seems the TZif2 file has an extra "LMT" in the first portion of the binary, which is supposed to be identical to the old TZif files. The extra "LMT" also seems to cause Solaris localtime() to behave differently. It would be better for Solaris compatibility if "LMT" was not included in the first portion of the TZif2 file, and if the first portion of a TZif2 file was identical to a TZif file except for the "2" in "TZif2". As an example using 32-bit 2005l localtime.c, this is the behavior difference of zdump for Indian/Cocos timezone between TZif format vs. TZif2 format: old TZif vs. new TZif2 Indian/Cocos: < Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:15:52 1901 CCT isds t=0 < Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:15:52 1901 CCT isds t=0 < Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:44:07 2038 CCT isds t=0 < Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:44:07 2038 CCT isds t=0 --- > Indian/Cocos Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:13:32 1901 LMT isds t=0 > Indian/Cocos Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:13:32 1901 LMT isds t=0 > Indian/Cocos Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 09:41:47 2038 LMT isds t=0 > Indian/Cocos Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 09:41:47 2038 LMT isds This is a dump of the Indian/Cocos TZif2 file: % od -xc ./Indian/Cocos 0000000 545a 6966 3200 0000 0000 0000 0000 0000 T Z i f 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0008 0000 5adc \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 \b \0 \0 Z 334 0000060 0000 4c4d 5400 4343 5400 0000 545a 6966 \0 \0 L M T \0 C C T \0 \0 \0 T Z i f 0000100 3200 0000 0000 0000 0000 0000 0000 0000 2 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000120 0000 0002 0000 0002 0000 0000 0000 0001 \0 \0 \0 002 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 001 0000140 0000 0002 0000 0008 ffff ffff 7c55 26a4 \0 \0 \0 002 \0 \0 \0 \b 377 377 377 377 | U & 244 0000160 0100 005a dc00 0000 005b 6800 044c 4d54 001 \0 \0 Z 334 \0 \0 \0 \0 [ h \0 004 L M T 0000200 0043 4354 0000 0000 000a 4343 542d 363a \0 C C T \0 \0 \0 \0 \0 \n C C T - 6 : 0000220 3330 0a00 3 0 \n 0000223 This is a dump of the Indian/Cocos TZif file: % od -xc /usr/share/lib/zoneinfo/Indian/Cocos 0000000 545a 6966 0000 0000 0000 0000 0000 0000 T Z i f \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 0000 0000 0000 0001 0000 0001 0000 0000 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 001 \0 \0 \0 \0 0000040 0000 0000 0000 0001 0000 0004 0000 5b68 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 \0 004 \0 \0 [ h 0000060 0000 4343 5400 0000 \0 \0 C C T \0 \0 \0 0000070 The following timezones (which seem to have no transitions) showed similar behavior differences with 2005l localtime.c and TZif vs. TZif2 formats: Africa/Bujumbura Africa/Kinshasa Africa/Lome Africa/Lubumbashi Atlantic/South_Georgia Indian/Christmas Indian/Cocos Pacific/Fakaofo Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Port_Moresby Pacific/Tarawa Pacific/Truk Pacific/Wake Pacific/Wallis

2 1

RE: next time zone package update
by Olson, Arthur David (NIH/NCI) [E] March 14, 2006

March 14, 2006

I'll also bundle in the LONG_LONG_MAX fix. --ado

1 0

next time zone package update
by Arthur David Olson March 14, 2006

March 14, 2006

My plan is to wait for Sri Lanka changes (which affect present and future rather than historical instants) then update the elsie ftp directory to contain old-tzcode-32-bit-binary-files.tar.gz (tz32code2006b.tar.gz renamed) and tzcode2006c.tar.gz (not tz64code2006c.tar.gz) and tzdata2006c.tar.gz (not tz64data2006c.tar.gz) Proposed code changes are at the end of this message; the changes would: 1. eliminate conditionalization on __STDC__ by assuming a standard-conforming compiler is in use; 2. avoid gcc warnings about format strings in asctime; 3. introduce binary search logic in localtime.c. At least for now, the plan is to forego size_t tweaks, changes in default zdump cutoff years, and elimination of the P (paramater) macro. --ado ------- asctime.c ------- *** /tmp/geta17330 Tue Mar 14 10:20:10 2006 --- /tmp/getb17330 Tue Mar 14 10:20:10 2006 *************** *** 11,17 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 11,17 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)asctime.c 8.2"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 23,29 **** /* ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ! ** At least some versions of gcc warn about the %02.2d; ignore the warning. */ /* ** All years associated with 32-bit time_t values are exactly four digits long; --- 23,30 ---- /* ** Some systems only handle "%.2d"; others only handle "%02d"; ** "%02.2d" makes (most) everybody happy. ! ** At least some versions of gcc warn about the %02.2d; ! ** we conditionalize below to avoid the warning. */ /* ** All years associated with 32-bit time_t values are exactly four digits long; *************** *** 37,43 **** --- 38,48 ---- ** The ISO C 1999 and POSIX 1003.1-2004 standards prohibit padding the year, ** but many implementations pad anyway; most likely the standards are buggy. */ + #ifdef __GNUC__ + #define ASCTIME_FMT "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %-4s\n" + #else /* !defined __GNUC__ */ #define ASCTIME_FMT "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %-4s\n" + #endif /* !defined __GNUC__ */ /* ** For years that are more than four digits we put extra spaces before the year ** so that code trying to overwrite the newline won't end up overwriting *************** *** 44,50 **** --- 49,59 ---- ** a digit within a year and truncating the year (operating on the assumption ** that no output is better than wrong output). */ + #ifdef __GNUC__ + #define ASCTIME_FMT_B "%.3s %.3s%3d %2.2d:%2.2d:%2.2d %s\n" + #else /* !defined __GNUC__ */ #define ASCTIME_FMT_B "%.3s %.3s%3d %02.2d:%02.2d:%02.2d %s\n" + #endif /* !defined __GNUC__ */ #define STD_ASCTIME_BUF_SIZE 26 /* ------- date.c ------- *** /tmp/geta17349 Tue Mar 14 10:20:10 2006 --- /tmp/getb17349 Tue Mar 14 10:20:10 2006 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.1"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)date.c 8.2"; /* ** Modified from the UCB version with the SCCS ID appearing below. */ *************** *** 352,364 **** /*ARGSUSED*/ static void - #if __STDC__ reset(const time_t newt, const int nflag) - #else /* !__STDC__ */ - reset(newt, nflag) - const time_t newt; - const int nflag; - #endif /* !__STDC__ */ { register int fid; time_t oldt; --- 352,358 ---- *************** *** 623,636 **** #define ATOI2(ar) (ar[0] - '0') * 10 + (ar[1] - '0'); ar += 2; static time_t - #if __STDC__ convert(register const char * const value, const int dousg, const time_t t) - #else /* !__STDC__ */ - convert(value, dousg, t) - register const char * const value; - const int dousg; - const time_t t; - #endif /* !__STDC__ */ { register const char * cp; register const char * dotp; --- 617,623 ---- *************** *** 734,751 **** */ static void - #if __STDC__ checkfinal(const char * const value, const int didusg, const time_t t, const time_t oldnow) - #else /* !__STDC__ */ - checkfinal(value, didusg, t, oldnow) - const char * const value; - const int didusg; - const time_t t; - const time_t oldnow; - #endif /* !__STDC__ */ { time_t othert; struct tm tm; --- 721,730 ---- *************** *** 804,819 **** } static void - #if __STDC__ iffy(const time_t thist, const time_t thatt, const char * const value, const char * const reason) - #else /* !__STDC__ */ - iffy(thist, thatt, value, reason) - const time_t thist; - const time_t thatt; - const char * const value; - const char * const reason; - #endif /* !__STDC__ */ { struct tm tm; --- 783,790 ---- ------- localtime.c ------- *** /tmp/geta17444 Tue Mar 14 10:20:12 2006 --- /tmp/getb17444 Tue Mar 14 10:20:12 2006 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.3"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 602,614 **** */ static const char * - #if __STDC__ getqzname(register const char *strp, const int delim) - #else /* !__STDC__ */ - getqzname(strp, delim) - register const char * strp; - const int delim; - #endif /* !__STDC__ */ { register int c; --- 602,608 ---- *************** *** 1263,1272 **** break; } } else { ! for (i = 1; i < sp->timecnt; ++i) ! if (t < sp->ats[i]) ! break; ! i = (int) sp->types[i - 1]; } ttisp = &sp->ttis[i]; /* --- 1257,1273 ---- break; } } else { ! register int lo = 1; ! register int hi = sp->timecnt; ! ! while (lo < hi) { ! register int mid = (lo + hi) >> 1; ! ! if (t < sp->ats[mid]) ! hi = mid; ! else lo = mid + 1; ! } ! i = (int) sp->types[lo - 1]; } ttisp = &sp->ttis[i]; /* ------- private.h ------- *** /tmp/geta17482 Tue Mar 14 10:20:12 2006 --- /tmp/getb17482 Tue Mar 14 10:20:12 2006 *************** *** 21,27 **** #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 8.1"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 21,27 ---- #ifndef lint #ifndef NOID ! static char privatehid[] = "@(#)private.h 8.2"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 152,166 **** */ /* ! ** SunOS 4.1.1 cc lacks prototypes. */ #ifndef P - #if __STDC__ #define P(x) x - #else /* !__STDC__ */ - #define P(x) () - #endif /* ! __STDC__ */ #endif /* !defined P */ /* --- 152,162 ---- */ /* ! ** If your compiler lacks prototypes, "#define P(x) ()". */ #ifndef P #define P(x) x #endif /* !defined P */ /* ------- zdump.c ------- *** /tmp/geta17586 Tue Mar 14 10:20:14 2006 --- /tmp/getb17586 Tue Mar 14 10:20:14 2006 *************** *** 1,4 **** ! static char elsieid[] = "@(#)zdump.c 8.1"; /* ** This code has been made independent of the rest of the time --- 1,4 ---- ! static char elsieid[] = "@(#)zdump.c 8.2"; /* ** This code has been made independent of the rest of the time *************** *** 130,140 **** #endif /* !defined TZ_DOMAIN */ #ifndef P - #if __STDC__ #define P(x) x - #else /* !__STDC__ */ - #define P(x) () - #endif /* !__STDC__ */ #endif /* !defined P */ extern char ** environ; --- 130,136 ---- *************** *** 475,488 **** } static time_t - #if __STDC__ hunt(char *name, time_t lot, time_t hit) - #else /* !__STDC__ */ - hunt(name, lot, hit) - char * name; - time_t lot; - time_t hit; - #endif /* !__STDC__ */ { time_t t; long diff; --- 471,477 ---- *************** *** 552,565 **** } static void - #if __STDC__ show(char *zone, time_t t, int v) - #else /* !__STDC__ */ - show(zone, t, v) - char * zone; - time_t t; - int v; - #endif /* !__STDC__ */ { register struct tm * tmp; --- 541,547 ----

3 2