April 2005 - tz - lists.iana.org

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