cal-persia.el disagrees with Iranian calendar in A.D. 2025

[Paul Eggert]

A time-zone database user reported a bug for the year 2025 in Iran.
This appears to be due to a disagreement between GNU Emacs's
cal-persia.el and the user's (German) source for the Persian calendar.
The problem occurs both with Emacs 21.4 and CVS head.

I enclose the user's email below. I confirmed that

(calendar-gregorian-from-absolute
(calendar-absolute-from-persian '(1 1 1404)))

returns (3 20 2025), so it does appear that cal-persia disagrees with
his source, which says that 1 Farvardin 1404 corresponds to 21 March
2025. I don't know whether this should be a code fix or an
enhancement (cal-iran.el, say?).

Subject: Iran calculated DST dates
Date: Wed, 30 Mar 2005 14:38:46 +0200
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.
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

[Ed Reingold]

The problem is that in 2025 the equinox will be close to noon in Iran--too
close to say precisely what the calendar will be: it will be either Mar 20 or
Mar 21 on the ASTRONOMICAL calendar. Part of the problem is that it is not
clear what location in Iran should be used, Tehran (which we chose) or 52.5 E.
The ARITHMETICAL calendar gives the Mar 20 date. What will the TRUE date be?
It's anybody's guess, but PROBABLY Mar 21.

I don't see that any sensible change is possible at this time to either Emacs
(which does not contain the mechanisms in place to implement the astronomical
calendar) nor in the time-zone data base.

Post by Paul Eggert
A time-zone database user reported a bug for the year 2025 in Iran.
This appears to be due to a disagreement between GNU Emacs's
cal-persia.el and the user's (German) source for the Persian calendar.
The problem occurs both with Emacs 21.4 and CVS head.
I enclose the user's email below. I confirmed that
(calendar-gregorian-from-absolute
(calendar-absolute-from-persian '(1 1 1404)))
returns (3 20 2025), so it does appear that cal-persia disagrees with
his source, which says that 1 Farvardin 1404 corresponds to 21 March
2025. I don't know whether this should be a code fix or an
enhancement (cal-iran.el, say?).

Subject: Iran calculated DST dates
Date: Wed, 30 Mar 2005 14:38:46 +0200
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.
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

[Paul Eggert]

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 <***@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

[Ed Reingold]

Post by Paul Eggert
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.

Post by Paul Eggert
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.

Post by Paul Eggert
* 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

[Roozbeh Pournader]

Post by Paul Eggert

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.

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.

The issue is only controversial in academic circles. It's not
controversial in legal circles at all. 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, and since the
original law is passed by the Majlis (parliament), there are only two
ways to change it:

1) The Guardian Council calling it void because of it being against
Islam or the Islamic Republic Constitution, which would be a really
weird thing to do, since it's Islamic (uses the year of Hegira of
Muhammed as its first year), and the calendar being "hejri-e
shamsi" (Solar Hegira-based) is mentioned in the Islamic Constitution.

2) The Majlis replacing it with a new law, which is again very
improbable since: a) almost every calendar authority believes that one
should stick to such an "accurate" calendar. This is based on my
discussions with both the current calendar authority (the High Council
of Calendar, appointed by Tehran University and empowered by the Board
of Ministers), and the previous one (Dr Iraj Malekpour, same appointment
and empowerment). b) It's very improbable that a majority of the Iranian
Majlis will even understand any proposal (or importance of such a
proposal) to adopt an arithmetic Persian calendar, specially since the
real difference is very rare. And c) Iranians traditionally celebrate
the moment of vernal equinox as the beginning of the new Persian year.

(Please understand that I am personally among the supporters of an
arithmetic Persian calendar.)

Post by Paul Eggert
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?

I really believe that the suggested change in GNU Emacs is fine, but one
should correct that single instance in tzdata and mention that an
astronomical calendar is practically used.

I'm not sure about Birashk's suggested leap year rule (which is based on
the wrong and overly simplistic assumptions that the average length of
the spring equinoctial year is the same as the average tropical year,
that the average will remain the same forever, and that the length of an
astronomical day is constant), but a very simpler one I checked (using
33-year cycles) will not differ from the astronomical one until sometime
in the 2070s.

roozbeh


roozbeh

[Paul Eggert]

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....

Thanks for making this clear. I'll update the tz database
accordingly; the only year this affects in the current database is
2025 Gregorian (both spring and fall transitions). I'll add Oscar's
comments for years after 2037, as a warning to future maintainers.

I'm not sure about Birashk's suggested leap year rule ... but a very
simpler one I checked (using 33-year cycles) will not differ from
the astronomical one until sometime in the 2070s.

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.

[Roozbeh Pournader]

Post by Paul Eggert
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.

roozbeh

[Ed Reingold]

Post by Roozbeh Pournader

Post by Paul Eggert
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.