- tz - lists.iana.org

Iranian time DST not availale for this year !
by Hamid Hashemi March 22, 2006

March 22, 2006

Hi, Following iranian goverment rule we won't any Daylight Saving rule in this year ( 2006-2007 ) and the times won't go backward or forward. I did fix the timezone file and attached it to this email. Please check and let me know if any correction required. -- Regards ================================================================= / Seyyed Hamid Reza / WINDOWS FOR NOW !! / / Hashemi Golpayegani / Linux for future , FreeBSD for ever / / Morva System Co. / ------------------------------------- / / Network Administrator/ hamid(a)morva.net , ICQ# : 42209876 / ================================================================ # Iran # From Roozbeh Pournader (2003-03-15): # This is an English translation of what I just found (originally in Persian). # The Gregorian dates in brackets are mine: # # Official Newspaper No. 13548-1370/6/25 [1991-09-16] # No. 16760/T233 H 1370/6/10 [1991-09-01] # # The Rule About Change of the Official Time of the Country # # The Board of Ministers, in the meeting dated 1370/5/23 [1991-08-14], # based on the suggestion number 2221/D dated 1370/4/22 [1991-07-13] # of the Country's Organization for Official and Employment Affairs, # and referring to the law for equating the working hours of workers # and officers in the whole country dated 1359/4/23 [1980-07-14], and # for synchronizing the official times of the country, agreed that: # # The official time of the country will should move forward one hour # at the 24[:00] hours of the first day of Farvardin and should return # to its previous state at the 24[:00] hours of the 30th day of # Shahrivar. # # First Deputy to the President - Hassan Habibi # # Update: President Ahmadinejad ignored the DST for Iranian Time on # 22 March 2006 # and Hamid Hashemi ( hamid(a)morva.net ) fixed the zonefile on # 22 March 2006 until 22 March 2007 # # From personal experience, that agrees with what has been followed # for at least the last 5 years. Before that, for a few years, the # date used was the first Thursday night of Farvardin and the last # Thursday night of Shahrivar, but I can't give exact dates.... # I have also changed the abbreviations to what is considered correct # here in Iran, IRST for regular time and IRDT for daylight saving time. # # From Roozbeh Pournader (2005-04-05): # The text of the Iranian law, in effect since 1925, clearly mentions # that the true solar year is the measure, and there is no arithmetic # leap year calculation involved. There has never been any serious # plan to change that law.... # # From Paul Eggert (2005-04-05): # Go with Shanks before September 1991, and with Pournader thereafter. # I used Ed Reingold's cal-persia in GNU Emacs 21.2 to check Persian dates, # stopping after 2037 when 32-bit time_t's overflow. # That cal-persia used Birashk's approximation, which disagrees with the solar # calendar predictions for the year 2025, so I corrected those dates by hand. # # From Oscar van Vlijmen (2005-03-30), writing about future # discrepancies between cal-persia and the Iranian calendar: # For 2091 solar-longitude-after yields 2091-03-20 08:40:07.7 UT for # the vernal equinox and that gets so close to 12:00 some local # Iranian time that the definition of the correct location needs to be # known exactly, amongst other factors. 2157 is even closer: # 2157-03-20 08:37:15.5 UT. But the Gregorian year 2025 should give # no interpretation problem whatsoever. By the way, another instant # in the near future where there will be a discrepancy between # arithmetical and astronomical Iranian calendars will be in 2058: # vernal equinox on 2058-03-20 09:03:05.9 UT. The Java version of # Reingold's/Dershowitz' calculator gives correctly the Gregorian date # 2058-03-21 for 1 Farvardin 1437 (astronomical). # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Iran 1978 1980 - Mar 21 0:00 1:00 D Rule Iran 1978 only - Oct 21 0:00 0 S Rule Iran 1979 only - Sep 19 0:00 0 S Rule Iran 1980 only - Sep 23 0:00 0 S Rule Iran 1991 only - May 3 0:00 1:00 D Rule Iran 1992 1995 - Mar 22 0:00 1:00 D Rule Iran 1991 1995 - Sep 22 0:00 0 S Rule Iran 1996 only - Mar 21 0:00 1:00 D Rule Iran 1996 only - Sep 21 0:00 0 S Rule Iran 1997 1999 - Mar 22 0:00 1:00 D Rule Iran 1997 1999 - Sep 22 0:00 0 S Rule Iran 2000 only - Mar 21 0:00 1:00 D Rule Iran 2000 only - Sep 21 0:00 0 S Rule Iran 2001 2003 - Mar 22 0:00 1:00 D Rule Iran 2001 2003 - Sep 22 0:00 0 S Rule Iran 2004 only - Mar 21 0:00 1:00 D Rule Iran 2004 only - Sep 21 0:00 0 S Rule Iran 2005 2007 - Mar 22 0:00 0 S Rule Iran 2005 2007 - Sep 22 0:00 0 S Rule Iran 2008 only - Mar 21 0:00 1:00 D Rule Iran 2008 only - Sep 21 0:00 0 S Rule Iran 2009 2011 - Mar 22 0:00 1:00 D Rule Iran 2009 2011 - Sep 22 0:00 0 S Rule Iran 2012 only - Mar 21 0:00 1:00 D Rule Iran 2012 only - Sep 21 0:00 0 S Rule Iran 2013 2015 - Mar 22 0:00 1:00 D Rule Iran 2013 2015 - Sep 22 0:00 0 S Rule Iran 2016 only - Mar 21 0:00 1:00 D Rule Iran 2016 only - Sep 21 0:00 0 S Rule Iran 2017 2019 - Mar 22 0:00 1:00 D Rule Iran 2017 2019 - Sep 22 0:00 0 S Rule Iran 2020 only - Mar 21 0:00 1:00 D Rule Iran 2020 only - Sep 21 0:00 0 S Rule Iran 2021 2023 - Mar 22 0:00 1:00 D Rule Iran 2021 2023 - Sep 22 0:00 0 S Rule Iran 2024 only - Mar 21 0:00 1:00 D Rule Iran 2024 only - Sep 21 0:00 0 S Rule Iran 2025 2027 - Mar 22 0:00 1:00 D Rule Iran 2025 2027 - Sep 22 0:00 0 S Rule Iran 2028 2029 - Mar 21 0:00 1:00 D Rule Iran 2028 2029 - Sep 21 0:00 0 S Rule Iran 2030 2031 - Mar 22 0:00 1:00 D Rule Iran 2030 2031 - Sep 22 0:00 0 S Rule Iran 2032 2033 - Mar 21 0:00 1:00 D Rule Iran 2032 2033 - Sep 21 0:00 0 S Rule Iran 2034 2035 - Mar 22 0:00 1:00 D Rule Iran 2034 2035 - Sep 22 0:00 0 S Rule Iran 2036 2037 - Mar 21 0:00 1:00 D Rule Iran 2036 2037 - Sep 21 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tehran 3:25:44 - LMT 1916 3:25:44 - TMT 1946 # Tehran Mean Time 3:30 - IRST 1977 Nov 4:00 Iran IR%sT 1979 3:30 Iran IR%sT

1 0

CEOs and Accountability
by GCC Events March 21, 2006

March 21, 2006

This mail can not be seen for non-HTML mail clients

1 0

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