* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 [not found] <200503302100.j2UL0wFG007410@emr.cs.iit.edu> @ 2005-03-31 7:18 ` Paul Eggert 2005-03-31 14:39 ` Ed Reingold 2005-04-05 16:14 ` Roozbeh Pournader 0 siblings, 2 replies; 8+ messages in thread From: Paul Eggert @ 2005-03-31 7:18 UTC (permalink / raw) Cc: bug-gnu-emacs, Oscar van Vlijmen, tz 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-03-31 7:18 ` cal-persia.el disagrees with Iranian calendar in A.D. 2025 Paul Eggert @ 2005-03-31 14:39 ` Ed Reingold 2005-04-05 16:14 ` Roozbeh Pournader 1 sibling, 0 replies; 8+ messages in thread From: Ed Reingold @ 2005-03-31 14:39 UTC (permalink / raw) Cc: bug-gnu-emacs, Oscar van Vlijmen, tz > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-03-31 7:18 ` cal-persia.el disagrees with Iranian calendar in A.D. 2025 Paul Eggert 2005-03-31 14:39 ` Ed Reingold @ 2005-04-05 16:14 ` Roozbeh Pournader 2005-04-05 22:02 ` Paul Eggert 1 sibling, 1 reply; 8+ messages in thread From: Roozbeh Pournader @ 2005-04-05 16:14 UTC (permalink / raw) Cc: Ed Reingold, bug-gnu-emacs, tz, Oscar van Vlijmen 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-04-05 16:14 ` Roozbeh Pournader @ 2005-04-05 22:02 ` Paul Eggert 2005-04-06 13:12 ` Roozbeh Pournader 0 siblings, 1 reply; 8+ messages in thread From: Paul Eggert @ 2005-04-05 22:02 UTC (permalink / raw) Cc: Ed Reingold, Oscar van Vlijmen, bug-gnu-emacs, tz 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-04-05 22:02 ` Paul Eggert @ 2005-04-06 13:12 ` Roozbeh Pournader 2005-04-06 16:30 ` Ed Reingold 0 siblings, 1 reply; 8+ messages in thread From: Roozbeh Pournader @ 2005-04-06 13:12 UTC (permalink / raw) Cc: Ed Reingold, bug-gnu-emacs, tz, Oscar van Vlijmen 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-04-06 13:12 ` Roozbeh Pournader @ 2005-04-06 16:30 ` Ed Reingold 0 siblings, 0 replies; 8+ messages in thread From: Ed Reingold @ 2005-04-06 16:30 UTC (permalink / raw) Cc: bug-gnu-emacs, Paul Eggert, tz, Oscar van Vlijmen > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <eggert@CS.UCLA.EDU>]
* cal-persia.el disagrees with Iranian calendar in A.D. 2025 @ 2005-03-30 17:29 ` Paul Eggert 2005-03-30 18:25 ` Ed Reingold 0 siblings, 1 reply; 8+ messages in thread From: Paul Eggert @ 2005-03-30 17:29 UTC (permalink / raw) Cc: bug-gnu-emacs 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: cal-persia.el disagrees with Iranian calendar in A.D. 2025 2005-03-30 17:29 ` Paul Eggert @ 2005-03-30 18:25 ` Ed Reingold 0 siblings, 0 replies; 8+ messages in thread From: Ed Reingold @ 2005-03-30 18:25 UTC (permalink / raw) Cc: bug-gnu-emacs, ovv 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 > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-04-06 16:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <200503302100.j2UL0wFG007410@emr.cs.iit.edu> 2005-03-31 7:18 ` cal-persia.el disagrees with Iranian calendar in A.D. 2025 Paul Eggert 2005-03-31 14:39 ` Ed Reingold 2005-04-05 16:14 ` Roozbeh Pournader 2005-04-05 22:02 ` Paul Eggert 2005-04-06 13:12 ` Roozbeh Pournader 2005-04-06 16:30 ` Ed Reingold [not found] <eggert@CS.UCLA.EDU> 2005-03-30 17:29 ` Paul Eggert 2005-03-30 18:25 ` Ed Reingold
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.