[tz] posix for asia/tehran is wrong

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Nov 30 15:50:46 UTC 2018


On 2018-11-30 01:41, Paul Eggert wrote:
> There is no simple Gregorian equivalent to the Iranian rules' use of the
> Persian calendar, so we might as well stick with the current Gregorian
> approximation for far-future years. That being said, this is a good time as
> any to extend the table of exact transitions past its current cutoff year
> 2037, as the 2037 cutoff dates back to when zic couldn't reliably handle
> dates past 2038. A reasonable cutoff for Iranian DST prediction is to stop
> just before the year 2091, as there is some controversy over how to interpret
> current Iranian law for that year. (Of course the DST rules will probably
> change before then...)
> Proposed patch attached.

You previously corrected the code output by hand, but now appear to do so in the
Lisp approximation, which means the following description is confusing:

-# 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.
+# I used the following code in GNU Emacs 25.2 to generate the "Rule Iran"
+# lines from 2008 through 2087.  This code uses Ed Reingold's cal-persia
+# which uses Birashk's approximation, and this disagrees with the solar
+# calendar predictions for the Persian years 1404 (Gregorian 2025)
+# and 1437 (Gregorian 2058), so this code fixes those two years by hand.

so I suggest something like the following:

-# which uses Birashk's approximation, and this disagrees with the solar
-# which uses Birashk's approximation, and disagrees with the solar
+# calendar predictions for the Persian years 1404 (Gregorian 2025)
-# and 1437 (Gregorian 2058), so this code fixes those two years by hand.
-# and 1437 (Gregorian 2058), so this code fixes those two years.

For occasional and non-Lispers, the included Emacs Lisp code is non-obvious: it
may be more helpful to provide the code in a separate file, which also clearly
documents its function in plain language, enhancing understanding and
implementation in other languages, and reference that.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.


More information about the tz mailing list