- tz - lists.iana.org

proposed patch for Nicaragua, Iran, etc.
by Paul Eggert April 17, 2005

April 17, 2005

Thanks for mentioning that; it's higher priority to fix this, as current timestamps are wrong in Nicaragua. Here are proposed changes to the TZ database that take this into account, along with other less-important changes that have been saved up. * Nicaragua is observing DST, as of this weekend. Thanks to Steffen Thorsen for this. * A fix for transitions in 2025 in Iran. Thanks to Oscar van Vlijmen for this info, and to Roozbeh Pournader and Ed Reingold for clarifications about the Iranian calendar. * A comment typo fixed for Mexico, and a table typo (that did not affect any transitions) for Libya. Thanks to Jesper Norgaard Welen for these fixes. =================================================================== RCS file: RCS/northamerica,v retrieving revision 2005.5 retrieving revision 2005.5.0.1 diff -pu -r2005.5 -r2005.5.0.1 --- northamerica 2005/02/07 21:19:42 2005.5 +++ northamerica 2005/04/12 08:11:31 2005.5.0.1 @@ -1427,7 +1427,7 @@ Zone America/Dawson -9:17:40 - LMT 1900 # Shanks reports that Baja was at -8:00 in 1922/1923. # Shanks says the 1930 transition in Baja was 1930-11-16. # Shanks reports no DST during summer 1931. -# Shanks reports a transition at 1032-03-30 23:00, not 1932-04-01. +# Shanks reports a transition at 1932-03-30 23:00, not 1932-04-01. # Shanks does not report transitions for Baja in 1945 or 1948. # Shanks reports southern Mexico transitions on 1981-12-01, not 12-23. # Shanks says Quintana Roo switched to -6:00 on 1982-12-02, and to -5:00 @@ -1931,11 +1931,28 @@ Zone America/Montserrat -4:08:52 - LMT 1 # Nicaragua seems to be back at -6:00 but I have not been able to find when # they changed from -5:00. # +# From Steffen Thorsen (2005-04-12): +# I've got reports from 8 different people that Nicaragua just started +# DST on Sunday 2005-04-10, in order to save energy because of +# expensive petroleum. The exact end date for DST is not yet +# announced, only "September" but some sites also say "mid-September". +# Some background information is available on the President's official site: +# http://www.presidencia.gob.ni/Presidencia/Files_index/Secretaria/Notas%20de… +# The Decree, no 23-2005 is available here: +# http://www.presidencia.gob.ni/buscador_gaceta/BD/DECRETOS/2005/Decreto%2023… +# +# From Paul Eggert (2005-04-12): +# The decree doesn't say anything about daylight saving, but for now let's +# assume that it is daylight saving and that they'll switch back on the +# 2nd Sunday in September. +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Nic 1979 1980 - Mar Sun>=16 0:00 1:00 D Rule Nic 1979 1980 - Jun Mon>=23 0:00 0 S Rule Nic 1992 only - Jan 1 4:00 1:00 D Rule Nic 1992 only - Sep 24 0:00 0 S +Rule Nic 2005 only - Apr 10 0:00 1:00 D +Rule Nic 2005 only - Sep 11 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Managua -5:45:08 - LMT 1890 -5:45:12 - MMT 1934 Jun 23 # Managua Mean Time? @@ -1943,7 +1960,7 @@ Zone America/Managua -5:45:08 - LMT 1890 -5:00 - EST 1975 Feb 16 -6:00 Nic C%sT 1993 Jan 1 4:00 -5:00 - EST 1998 Dec - -6:00 - CST + -6:00 Nic C%sT # Panama # Zone NAME GMTOFF RULES FORMAT [UNTIL] =================================================================== RCS file: RCS/africa,v retrieving revision 2001.4 retrieving revision 2001.4.0.1 diff -pu -r2001.4 -r2001.4.0.1 --- africa 2001/10/09 17:31:30 2001.4 +++ africa 2005/04/12 08:11:31 2001.4.0.1 @@ -317,7 +317,7 @@ Rule Libya 1985 only - Apr 6 0:00 1:00 Rule Libya 1986 only - Apr 4 0:00 1:00 S Rule Libya 1986 only - Oct 3 0:00 0 - Rule Libya 1987 1989 - Apr 1 0:00 1:00 S -Rule Libya 1987 1990 - Oct 1 0:00 0 - +Rule Libya 1987 1989 - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Tripoli 0:52:44 - LMT 1920 1:00 Libya CE%sT 1959 =================================================================== RCS file: RCS/asia,v retrieving revision 2005.8 retrieving revision 2005.8.0.1 diff -pu -r2005.8 -r2005.8.0.1 --- asia 2005/04/04 15:24:32 2005.8 +++ asia 2005/04/12 08:11:31 2005.8.0.1 @@ -476,12 +476,33 @@ Zone Asia/Jayapura 9:22:48 - LMT 1932 No # 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 Paul Eggert (2003-03-15) +# +# 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. -# The Persian calendar is based on the sun, and dates after around 2050 -# are approximate; stop after 2037 when 32-bit time_t's overflow. +# 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 @@ -519,10 +540,10 @@ 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 2025 - Mar 21 0:00 1:00 D -Rule Iran 2024 2025 - Sep 21 0:00 0 S -Rule Iran 2026 2027 - Mar 22 0:00 1:00 D -Rule Iran 2026 2027 - 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

2 2

Time changed in Managua/Nicaragua
by Antonio Gallardo April 16, 2005

April 16, 2005

Hi: Since april 10th 2005, my country's goverment (Nicaragua) decided to use daylight time (CDT). Before we used CST without daylight time: In spanish there is a lot of info about, perhaps you could use a web translator to see this: http://www.chron.com/cs/CDA/story.es.hts/sp/nws/3127270 And here is the news in the goverment oficial site: http://www.presidencia.gob.ni/Presidencia/Files_index/Secretaria/Notas%20de… Don't hesitate to contact me for more info. Best Regards, Antonio Gallardo.

1 0

Obsolete historic tz change for Libya
by Jesper Norgaard Welen April 12, 2005

April 12, 2005

In the timezone rules for Libya, it seems to me there is an obsolete timezone change, at 1.st October 1990 at 0:00, because the Libya Rule is only used in country Libya until 4.th. of May 1990: Rule Libya 1987 1989 - Apr 1 0:00 1:00 S Rule Libya 1987 1990 - Oct 1 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Tripoli 0:52:44 - LMT 1920 1:00 Libya CE%sT 1959 2:00 - EET 1982 1:00 Libya CE%sT 1990 May 4 # The following entries are all from Shanks; # the IATA SSIM data contain some obvious errors. 2:00 - EET 1996 Sep 30 1:00 - CET 1997 Apr 4 1:00 1:00 CEST 1997 Oct 4 2:00 - EET Therefore I suggest that the timezone rule be corrected to Rule Libya 1987 1989 - Oct 1 0:00 0 - This is not a big problem, but might induce some confusion in the reader of the tz database. If there is any other reason to keep this line, please state why. 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 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 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

U.S. Congress may extend daylight savings time
by Jonathan Lennox April 8, 2005

April 8, 2005

A heads-up to everyone on the list: "Lawmakers crafting energy legislation approved an amendment Wednesday to extend daylight-saving time by two months, having it start on the first Sunday in March and end on the last Sunday in November." <http://www.cnn.com/2005/POLITICS/04/07/daylight.saving.ap/index.html> -- Jonathan Lennox lennox at cs dot columbia dot edu

1 1

FW: China's Daylight Saving Time
by Olson, Arthur David (NIH/NCI) April 7, 2005

April 7, 2005

Xiaotian Sun is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Xiaotian Sun [mailto:sun.xiaotian@gmail.com] Sent: Thursday, April 07, 2005 4:03 PM To: tz(a)lecserver.nci.nih.gov Subject: China's Daylight Saving Time Hi, About the Summer Time (Daylight Saving Time) China observed from 1986 to 1991, the effective time is 2:00, not 0:00 as listed in the zoneinfo/asia file. Xiaotian Sun

2 1

Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025
by Ed Reingold April 6, 2005

April 6, 2005

> On Tue, 2005-04-05 at 15:02 -0700, Paul Eggert wrote: > > This suggests that cal-persia.el could be changed as well, as its > > practical use is (I think) for predicting dates in Iran. I'm hesitant > > to propose a change myself, though, as I'm not an expert in either the > > calendar or the code. > > Ed could probably help with that... I don't know any LISP, and every > useful thing I know about computing astronomical calendars comes from > his book. As I have said before, the mechanisms needed to do the Persian astronomical calendar are not in the existing Emacs code; the algorithms in my Calendrical Calculations will never be released under the GNU license, so somebody would have to come up with entirely new algorithms and implement them in Emacs-Lisp. As it stands, the arithmetical Persian calendar is an excellent approximation to the astronomical version--a much better approximation than the GNU Emacs arithmetic approximation to the Islamic calendar is to the true observational Islamic calendar. I don't see any reasonable changes to cal-persia.el as being needed. The documentation could be modified to state that the calendar as implemented is a close approximation to the astronomical version. I leave that up to others.

1 0

Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025
by Paul Eggert April 5, 2005

April 5, 2005

Ed Reingold <reingold(a)emr.cs.iit.edu> writes: > For the TZ data base, what is the point of making one assumption over the > other? Neither will be known right or wrong for another 20 years. It's mostly a matter of documenting the projected daylight-saving transitions. Currently we project through 2038 (when 32-bit time_t values roll over). We are adding support for 64-bit time_t values, though, and at some point we'll probably start projecting a bit further (50 years, say? we haven't decided). The cutoff is somewhat arbitrary, but going a few decades into the future helps give novices a better feel for the complexity of the projections. By the way, in researching this I found the following reference useful: M. Heydari-Malayeri (Paris Observatory), A concise review of the Iranian calendar (2005-02-15), <http://wwwusr.obspm.fr/~heydari/divers/ir-cal-eng.html> It mentions the March 20, 2025 discrepancy, and it has some interesting and not-altogether-positive things to say about the method used in GNU Emacs. I hadn't realized how controversial this area is. > For Emacs, it's irrelevant because it does not contain the Persian > astronomical calendar Thanks for clarifying this. Would it be appropriate to make the following change to the GNU Emacs user documentation, if only to help forestall future bug reports in this area? 2005-03-31 Paul Eggert <eggert(a)cs.ucla.edu> * calendar.texi (Calendar Systems): Mention that the Persian calendar implemented is the arithmetical calendar of Birashk. --- calendar.texi.~1.33.~ 2005-03-28 16:30:06 -0500 +++ calendar.texi 2005-03-31 01:46:45 -0500 @@ -691,6 +691,12 @@ Their calendar consists of twelve months days, the next five have 30 days, and the last has 29 in ordinary years and 30 in leap years. Leap years occur in a complicated pattern every four or five years. +The calendar implemented here is the arithmetical Persian calendar +championed by Birashk, based on a 2,820-year cycle. It differs from +the astronomical Persian calendar, which is based on astronomical +events. As of this writing the first future discrepancy is projected +to occur on March 20, 2025. It is currently not clear what the +official calendar of Iran will be that far into the future. @cindex Chinese calendar The Chinese calendar is a complicated system of lunar months arranged

2 2

Iran calculated DST dates
by Oscar van Vlijmen April 5, 2005

April 5, 2005

I checked the DST on/off dates for Iran. It appears that the dates were calculated with the arithmetic 'Persian' calendar in mind. Since 1925 an astronomical calendar is in use, so I read. There is one day difference between these two calendar systems in the Gregorian year 2025, so there is one error in the list of DST rules for Iran if indeed the astronomical calendar system is used. The astronomical Iranian calendar has 1 Farvardin 1404 on 21 March 2025 Gregorian, so DST on is per 22 March 2025 0:00, and 30 Shahrivar 1404 is on 21 September 2025 Gregorian, so DST off is per 22 September 2025 Gregorian. The vernal equinox in 2025 Gregorian is at around 09:01 UTC on March 20, so around 12:27 Tehran 'solar' time. This is past 12:00, hence 1 Farvardin is on March 21. A long article about the Iranian calendar (in German): Iranische Zeitrechnungen, Nikolaus A. Bär, 2004. See the chapter "Der neuiranische Kalender", with a French translation of the 1925 law. http://www.nabkal.de/irankal.html I checked the Iranian calendar dates with the Java application by Reingold/Dershowitz, version 2.1. http://emr.cs.iit.edu/home/reingold/calendar-book/Calendrica.html And the mentioned vernal equinox date/time with 2 different astronomical programs. Oscar van Vlijmen 2005-03-30

2 1

Tzcode2005h.tar.gz and tzdata2005h.tar.gz
by Olson, Arthur David (NIH/NCI) April 4, 2005

April 4, 2005

The files... ftp://elsie.nci.nih.gov/pub/tzcode2005h.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2005h.tar.gz ...are now available. These reflect the changes circulated last week on the time zone mailing list by Paul Eggert. They also contain the minor changes to Makefile and zdump.c to produce more useful output when doing a "make typecheck". With only some technical fixes to the proposed 64-bit changes in hand, I'll hold off on distributing these; I welcome insights on whether the general approach is sound. --ado

1 0

Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025
by Ed Reingold March 31, 2005

March 31, 2005

> It mentions the March 20, 2025 discrepancy, and it has some > interesting and not-altogether-positive things to say about the method > used in GNU Emacs. I hadn't realized how controversial this area is. Had I realized how controversial it was, I would not have included it in Emacs, I only learned that is 1998, long after the code was released. Still, it is not a bad approximation, but it should be labeled as such. > Thanks for clarifying this. Would it be appropriate to make the > following change to the GNU Emacs user documentation, if only to help > forestall future bug reports in this area? Your change (below) is fine. > > 2005-03-31 Paul Eggert <eggert(a)cs.ucla.edu> > > * calendar.texi (Calendar Systems): Mention that the Persian > calendar implemented is the arithmetical calendar of Birashk. > > --- calendar.texi.~1.33.~ 2005-03-28 16:30:06 -0500 > +++ calendar.texi 2005-03-31 01:46:45 -0500 > @@ -691,6 +691,12 @@ Their calendar consists of twelve months > days, the next five have 30 days, and the last has 29 in ordinary years > and 30 in leap years. Leap years occur in a complicated pattern every > four or five years. > +The calendar implemented here is the arithmetical Persian calendar > +championed by Birashk, based on a 2,820-year cycle. It differs from > +the astronomical Persian calendar, which is based on astronomical > +events. As of this writing the first future discrepancy is projected > +to occur on March 20, 2025. It is currently not clear what the > +official calendar of Iran will be that far into the future. > > @cindex Chinese calendar > The Chinese calendar is a complicated system of lunar months arranged

1 0