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

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


> From: Oscar van Vlijmen <ovv@hetnet.nl>
> 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.
> 
> 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
> 

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

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


> 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?).
> 
> 
> > From: Oscar van Vlijmen <ovv@hetnet.nl>
> > 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.
> > 
> > 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
> > 

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

[Paul Eggert]

Ed Reingold <reingold@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@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

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

[Ed Reingold]

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

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

[Roozbeh Pournader]

On Thu, 2005-03-31 at 02:18 -0500, Paul Eggert wrote:
> Ed Reingold <reingold@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.
> 
> 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.

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

> 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

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

[Paul Eggert]

Roozbeh Pournader <roozbeh@farsiweb.info> writes:

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

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

[Roozbeh Pournader]

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.

roozbeh

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

[Ed Reingold]

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