The Rectified Hebrew Calendar

by Dr. Irv Bromberg, University of Toronto, Canada

[Click here to go back to the Hebrew Calendar Studies home page]

Join the Calendars LISTSERV

---

Menu of Topics:

1. Benefits and "Executive Summary"
2. Overview of the Problem
3. The 353-Year Leap Cycle of the Rectified Hebrew Calendar
4. Features of the Rectified Hebrew Calendar
5. Sources for Astronomical Algorithms to Validate Calendar Performance
6. What if the Observational Hebrew Calendar is Reinstated?
7. Fixed Dates — the Rata Die
8. Calculation Precision — the Limitations of "Floating Point" Arithmetic
9. Copying Formulae or Statements and Pasting into Other Applications
10. The Locale in Jerusalem
11. The Hebrew Calendar Mode
12. The Number of Prior Elapsed Months — the ElapsedMonths Function
13. Is it a Hebrew Leap Year?
14. Patterns in the Intervals Between Leap Years
15. Talmudic Temporal Time (TTT)
16. The MoladMoment Function
17. The MoladAdjustment Function
18. The Progressively Shorter Progressive Molad Interval
19. Molad Intervals Determine Hebrew Calendar Mean Year Length
20. The First Day of Tishrei (Rosh Hashanah) — the HebrewNewYear Function
21. How Many Days are in Hebrew Calendar Years?
22. The First Day of Nisan — the NisanFirstDay Function
23. The HopToNextMonth Function
24. The FixedToHebrew Function
25. The HebrewToFixed Function
26. The HebrewMonthLength Function
27. Converting Hebrew Dates
28. Checking if a Date is Valid
29. Advanced Topics
30. Comments and Suggestions Received

---

Benefits and "Executive Summary"

1. If adopted, this calendar will halt and reset the solar (seasonal) drift of the traditional Hebrew calendar, restoring its alignment relative to the spring equinox back to its original state, by replacing the 7 leap months per 19-year Metonic cycle with a much more accurate cycle having 130 leap months per 353 years. Each fixed arithmetic 353-year cycle is inherently and automatically composed of 9 repeated 19-year sub-cycles, a sub-cycle truncated to 11 years by omitting 8 years containing 3 leap months, and a further 9 repeated 19-year sub-cycles.
2. Using a progressive molad, this calendar will also halt and reset the lunar (molad) drift of the traditional Hebrew calendar, restoring its alignment relative to the actual New Moon back to its original average state, by adjusting the molad to track the average New Moon interval, which is getting progressively shorter by about 27+¹/₃ microseconds or ⁴¹/₅ "microparts" per month. Over the long term, this molad rectification also slightly yet steadily shortens the calendar mean year, which will extend the rectified Hebrew calendar's ability to maintain excellent alignment relative to the spring equinox for longer than any other fixed arithmetic calendar ever devised.
3. In the era of the Maccabees the reference meridian of longitude for the traditional molad was midway between the Nile River and the end of the Euphrates River, but it drifts eastward at an accelerating rate and is currently near Qandahar, Afghanistan! The progressive molad as proposed herein fixes the molad reference to the meridian of Jerusalem, although a reasonable alternative would be to restore it to its original meridian.
4. In the present era (5766- 6000) the rectified Hebrew calendar agrees on the month with the traditional Hebrew calendar in more than 80% of months, and also agrees on the date in almost 73% of months, notwithstanding its modified leap cycle and progressive molad, and even with the solar drift and lunar drift of the traditional Hebrew calendar.
5. There will be many opportunities to switch from the traditional Hebrew calendar to the rectified Hebrew calendar without any objectionable date jump or repetition, because the two calendars often agree for many consecutive months, typically from Nisan through Adar or beyond. Between years 5766 through 6000 there will be 153 identical years from Nisan through Adar (over 65% of years), and 126 identical from Tishrei through Elul (almost 54% of years). The current period of perfect agreement began on 1 Nisan 5777 and will continue through to 29 Cheshvan 5784, inclusive. The last Tishrei through Elul match will be year 8585 and the last Nisan through Adar match will be the years 10979-10980. The last matching month will be Adar 11094.
6. This calendar employs 100% fixed arithmetic, simple enough to determine using a basic calculator.
7. Although much of the arithmetic presented here is novel, in the sense that I have not seen Hebrew calendar arithmetic carried out quite this way anywhere else, simply setting Mode = Traditional will make all of the arithmetic exactly equivalent to the traditional Hebrew calendar, useful because you can:
   • use it to verify the correct operation of all functions that are in-common with the rectified Hebrew calendar, either against calendar hardcopies or in comparison with another implementation of the traditional Hebrew calendar arithmetic, if available,
   • use it to interconvert rectified and traditional Hebrew calendar dates,
   • or use it to do your own comparative evaluations of the rectified and traditional Hebrew calendars.
8. Aside from the astronomically more accurate leap cycle and progressive molad, this calendar obeys all rules and shares all properties with the traditional Hebrew calendar, including the traditional Rosh Hashanah postponement rules and fixed month lengths. For compatibility with the progressively shorter progressive molad intervals, the postponement arithmetic documented herein employs innovative simple direct logic that automatically adapts to the contemporary mean lunation interval, thereby avoiding out-of-bounds year lengths.
9. The rectified Hebrew calendar is fully compatible with the traditional rules for the weekly Torah reading cycle (Parshat HaShavuah).
10. The rectified Hebrew calendar is hereby (by means of this web page) documented for implementation in computer systems and placed it in the public domain as a demonstration of the ease with which it can be put into practice, and to encourage its use and adoption.
11. This calendar was developed by stagewise simplification of my astronomical Hebrew calendar, serially replacing each of its astronomical algorithms and equations with incrementally simpler fixed arithmetic approximations.
12. Unlike astronomical or classical observational calendars, all dates generated by this rectified Hebrew calendar are predictable and reproducible for the past and future. This is important for calendrical calculations, such as calculating the difference between any two dates, and finding a past or future date that is a specified number of days before or after a given date.

A special "Thank You!" to Daniel Barron of Bet Shemesh, Israel, who during his visit to Toronto during the south solstice of 5766 (2005 AD) reviewed the properties of the developing Rectified Hebrew calendar, which at that time employed advance / postpone logic for Rosh Hashanah (inherited from my Astronomical Hebrew calendar). Daniel insisted that it must use Rosh Hashanah postponement rules that would be fully compatible with the traditional rules, so that all traditional Hebrew calendar "rules of thumb" would remain valid. This proved to be very difficult because the progressively shorter molad interval precluded using fixed cutoff times for the 3rd and 4th postponement rules. I consulted several Hebrew calendar experts and mathematicians to no avail. Ultimately, I found the solution in Rambam's discussion of the Rosh Hashanah postponement rules in Hilchot Kiddush HaChodesh! The resulting calendar is much more traditionally acceptable, so I thank Daniel for stressing the importance of seeking such a solution.

Overview of the Problem

As I have documented separately (see "The Seasonal Drift of the Traditional (Fixed Arithmetic) Hebrew Calendar"), in the present era the average year of the traditional Hebrew calendar is almost 6+¹/₂ minutes longer than the mean northward equinoctial year (spring equinox to the next spring equinox in the northern hemisphere). This causes the average moment of the northward equinox to drift progressively earlier in the Hebrew calendar year, at a rate that is currently about one day earlier per 220 years. Until today the average equinox has drifted about 6 days earlier than the start of Nisan, in Jerusalem. This equinox drift can be easily arrested and corrected by "rectifying" the Hebrew calendar leap rule, as explained herein.

The mean northward equinoctial year (average length of year from northern hemisphere spring equinox until the next spring equinox) is about 365.242362 mean solar days, or 365 days, 5 hours 49 minutes and 0 seconds. For the past 5-6 millennia this equinoctial year length was almost constant, and it will continue to be nearly constant for the next 3-4 millennia, but after that it will get shorter at an accelerating rate. For an explanation of why this will happen, and for more information about the changing lengths of the seasons and the lengths of the equinoctial and solstitial years, please see my web page entitled "The Lengths of the Seasons" at <http://individual.utoronto.ca/kalendis/seasons.htm>.

Currently the duration of the lunation from New Moon (solar-lunar conjunction) to New Moon (the Mean Synodic Month) is about 29.530587665 mean solar days, but is getting shorter by about ¹/₃ second per millennium or ¹/_3164169060 mean solar days per elapsed lunar month, or approximately 27+¹/₃ microseconds or ⁴¹/₅ "microparts" per lunar month. Currently the Mean Synodic Month is almost ³/₅ second or ⁹/₅₀ of a part shorter than the traditional Hebrew calendar molad interval of 29 days 12 hours 44 minutes ¹⁰/₃ seconds = ⁷⁶⁵⁴³³/₂₅₉₂₀ days = 29.530594135802469... days (in the decimal representation of the exact fraction the underscored digits repeat forever). This growing excess of the traditional molad interval over the actual mean synodic month is causing the traditionally calculated molad moments to drift progressively later with respect to the actual mean lunar conjunctions, and the drift rate is accelerating. Please see my web page entitled "The Molad of the Hebrew Calendar".

In the traditional (fixed arithmetic) Hebrew calendar, 19 years have exactly 235 lunar months, each of 29 days 12 hours 44 minutes ¹⁰/₃ seconds, which yields a mean calendar year length of 365+²⁴³¹¹/₉₈₄₉₆ days = 365 days 5 hours 55 minutes and (25+²⁵/₅₇ seconds or 7+¹²/₁₉ chalakim) ≈ 365.2468222 days. This Metonic cycle of years, named after the Athenian astronomer Meton, who published it in the year 432 BC (but previously known to ancient Babylonian and Chinese astronomers), presently is too long by about 6 minutes and 25+²⁵/₅₇ seconds per year, relative to the mean length of the northward equinoctial year. In 19 non-leap years there are 12 × 19 = 228 months, so this cycle requires 235 – 28 = 7 leap months per cycle to make up the full complement of 235 months. Traditionally the leap years of each 19-year cycle are years 3, 6, 8, 11, 14, 17, and 19:

Leap Month is required if the remainder of ( 7 × hYear + 1 ) / 19 is less than 7.
With 7 leap years per 19-year cycle, the average interval between leap years = ¹⁹/₇ ≈ 2.7142857 years.

The latest instances of Passover, relative to the northward equinox, always occur in the 8th year of each 19-year cycle, such as the recent year 5765, which, relative to the equinox, was the latest Passover in history, starting a bit more than 34 days after the equinox. In the present era, Passover falls later than the Chodesh haAviv limit (first month of spring) specified in the Torah more than 20% of the time (for 13 months from the start of Adar Rishon in years 8, 19, 11 of each 19-year cycle until the end of the next Shevat, and starting soon year 3 of each cycle will also be a month late). Due to the future drift acceleration, the latest instances of Passover will first hit the north solstice (summer solstice for the northern hemisphere) much sooner than would be expected from the present rate of drift, around Hebrew year 16,652. Pesach Sheini (Second Passover, on the 14th of Iyar, one month after Passover) which used to be an opportunity for those who were ritually impure or too far away during Passover to bring a Passover offering to the Temple in Jerusalem, will first hit the north solstice before Hebrew year 11000.

Extrapolating the traditional Hebrew calendar back to the era of Hillel ben Yehudah in Hebrew year 4119, the beginning of Nisan in the first year of each 19-year cycle was near the moment of the northward equinox (in terms of Jerusalem mean solar time). This would have had the effect that the first day of Passover would land midway between the equinox and the Chodesh ha-Aviv limit that is specified in the Torah, as shown in this chart 39 KB. Note that the 8th year of each 19-year cycle is always the latest and the 16th year is always the earliest with respect to the equinox.

At present the equinox-relative alignment of the first year of each 19-year Hebrew calendar cycle is about 7 days later than it was at the advent of the traditional Hebrew calendar in 4119. The year 5765 was the 8th year of the present 19-year cycle, therefore the first day of Passover 5765 was later than it has ever been in history, with respect to the equinox, as shown in this chart 40 KB.

Overall, the Traditional Hebrew calendar is drifting late with respect to the northward equinox at the rate of about one day later per 220 years, so that around 6000 years after Hillel ben Yehudah the Traditional Hebrew calendar it will "expire", in the sense that the first day of Passover will never again be observed within the Chodesh ha-Aviv limit, as shown in this chart 281 KB. Furthermore, the calendar is drifting further from the equinox at an accelerating rate, although from the previous charts that is not obvious, due to the scale employed for the Y-axis and because the X-axis extends "only" to Hebrew year 10000. The drift away from the equinox is more apparent on this chart of the first day of Nisan extending to Hebrew year 21000 57 KB. For an explanation as to what is causing the drift to accelerate please see my "Lengths of the Seasons" web page at <http://individual.utoronto.ca/kalendis/seasons.htm>.

The 353-Year Leap Cycle of the Rectified Hebrew Calendar

A more accurate Hebrew calendar needs an integer number of lunar months that fit more accurately into an integer number of solar years. This is easy to calculate by simply dividing the length of the actual astronomical average solar year by the length of the actual astronomical average lunar month:

Mean Northward Equinoctial Year / Mean Synodic Month

≈ ( 365 days 5 hours 49 minutes 0 seconds ) / ( 29 days 12 hours 44 minutes 2 ¹¹/₁₅ seconds )

= ( 365 + ⁵/₂₄ + ⁴⁹/₁₄₄₀ days ) / ( 29 + ¹²/₂₄ + ⁴⁴/₁₄₄₀ + ( ⁴¹/₁₅ ) / 86400 days )

= ( ⁵²⁵⁹⁴⁹/₁₄₄₀ ) / ( ^38271641/_1296000 )

= ^473354100/_38271641 = 473,354,100 months in 38,271,641 years!

This result, although representing the original ratio with "perfect" accuracy, would be absurdly inconvenient as a calendar leap cycle, so we need to find a numerically simple fraction that approximates this ratio using a reasonably short leap cycle. This approximation is easily obtained as the 6th convergent of the continued fraction for the above ratio:

^473354100/_38271641 = ≈ = ⁴³⁶⁶/₃₅₃

Therefore, 4366 lunar months in 353 solar years is an excellent approximation.

By way of comparison, note that the traditional Metonic cycle with 235 months in 19 years is the 5th convergent of the same ratio, but the large jump in a_n value (a₆ = 18) indicates that the 6th convergent is a much more accurate approximation. The 7th convergent has a₇ = 8, yielding the approximation ³⁵¹⁶³/₂₈₄₃, but a 2843-year leap cycle seems inconveniently long for the slight further improvement in accuracy, and, because future astronomical changes in the equinoctial year and synodic month are inevitable, it would be futile to force the leap cycle approximation beyond the 6th convergent.

Dr. William Moses Feldman (1880-1939, originator of the term "biomathematics") proposed an improved Hebrew calendar leap cycle of 334 years having 123 leap years and a total of 4131 months per cycle, also based on the continued fraction method, on page 208 of his book Rabbinical Mathematics and Astronomy (Hermon Press, New York, 1931). He calculated a shorter optimal cycle length because he used what he called the Tropical Year length of 365 days 5 hours 48 minutes 46 seconds = 365+¹⁰⁴⁶³/₄₃₂₀₀ = 365.242199074... days (about 14 seconds too short relative to the present-era mean northward equinoctial year) and he used a Lunar Year length of 354 days 8 hours 48 minutes 36 seconds = 354+⁸⁸¹/₂₄₀₀ = 354.367083... days, which corresponds to 29+¹⁵²⁸¹/₂₈₈₀₀ = 29 days 12 hours 44 minutes 3 seconds ≈ 29.53059027... days per lunar cycle (about ¹/₃ second shorter than the traditional molad interval, yet almost ¹/₃ second too long relative to the present era mean synodic month). Rather than the Mean Tropical Year (which applies only to atomic time), it is the mean northward equinoctial year that is the appropriate year length to keep Nisan aligned with the northward equinox, so for Hebrew calendar purposes the 334-year cycle is not as accurate as the 353-year cycle.

For further information about continued fractions, see <http://mathworld.wolfram.com/ContinuedFraction.html>. An easier-to-understand and more comprehensive explanation is at <http://en.wikipedia.org/wiki/Continued_fraction>.The following are continued fraction calculators that you can freely use on-line:

This one shows intermediate values used to compute the continued fraction, and its introductory web page offers a full explanation about continued fractions:
<http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfCALC.html>

This one displays interesting information when the user hovers the mouse pointer over each convergent value:
<http://wims.unice.fr/wims/wims.cgi?module=tool/number/contfrac.en>

In 353 non-leap years there are 12 × 353 = 4236 regular months, so this cycle requires 4366 – 4236 = 130 leap years per cycle to make up the full complement of 4366 months. The cycle mean year is presently (using the progressive molad) equal to ( 29 days 12 hours 44 minutes 2 ¹¹/₁₅ seconds ) days × 4366 months / 353 years ≈ 365 days 5 hours 48 minutes 57+³/₅ seconds per year, or only about 2+²/₅ seconds too short per year (whereas if the traditional molad interval were used then the mean year would be about 5 seconds too long at present) [by contrast note that the Gregorian cycle mean year, with 97 leap days per 400 years, is currently about 12 seconds too long].

The leap status of the year is calculated according to a 353-year leap cycle having 130 leap years that are at intervals as uniformly spread as possible. The leap rule is:

Leap Month is required if the remainder of ( 130 × hYear + 268 ) / 353 is less than 130.
With 130 leap years per 353-year cycle, the average interval = ³⁵³/₁₃₀ ≈ 2.7153846 years.

Note that this leap rule is not "more complicated" than the traditional leap rule of the 19-year cycle, since the same arithmetic operations are required, with mere substitution of more accurate numeric constants. Either way, most people would need the assistance of a calculating device.

(The derivation of the value +268 is explained in the discussion of the arithmetic for the isHebrewLeapYear353 function, below.)

The number 353 happens to be a prime number. The integers that divide into 4366 are 2, 37, 59, 74, 118, and 2183, of which 2, 37 and 59 are prime numbers. The integers that divide into 130 are 2, 5, 10, 13, 26, and 65, of which 2, 5 and 13 are prime numbers.

The effect of this leap cycle change is to slightly alter the distribution of leap years. There is hardly any change in the number of leap years over any long span of years. It does not affect the alignment of the months with respect to the lunar cycle, but it does arrest the drift of the rectified Hebrew calendar with respect to the solar cycle. Over a few centuries only fractional differences accumulate — in 353 years there are exactly 130 leap months in this more accurate leap cycle, whereas the traditional 19-year leap cycle has an average of 130+¹/₁₉ leap months. Thus it takes 19 × 353 = 6707 years for a full month difference to accumulate between this improved leap cycle and the traditional. As the difference accumulates, the traditional Hebrew calendar is one month behind the rectified Hebrew calendar more and more frequently (in the present era this is true in 20.8% of months). Eventually the traditional Hebrew calendar will be permanently one month late, because over the course of 6707 years the traditional leap cycle has exactly 2471 leap months whereas the 353-year cycle has exactly 2470 leap months (the last matching month will be Adar 11094). After that the traditional Hebrew calendar will be 1 or 2 months late, with 2 months late occurring more and more frequently until it is permanently 2 months late, and so on. Between years 5766 through 6000 there will be 153 identical years from Nisan through Adar (over 65% of years), and 126 identical from Tishrei through Elul (almost 54% of years), with the current period of perfect agreement having started on 1 Nisan 5777 and continuing through 29 Cheshvan 5784, inclusive. As the traditional Hebrew calendar drifts later and later with respect to the equinox, the intervals between identical years will become progressively longer — the last Tishrei through Elul match will occur in year 8585 and the last Nisan through Adar match in years 10979-10980.

The reason for the higher match rate from Nisan to Adar is that the calendars usually start to match after the rectified Hebrew calendar inserts its leap month, and they typically stop matching when the traditional Hebrew calendar inserts its leap month, unless the 130/353 cycle agrees on the leap status for that year. Single- or double-day differences occasionally occur starting after Cheshvan or Kislev when, due to progressive vs traditional molad differences, the two calendars disagree on the Rosh Hashanah postponement.

Click here to see how often the Traditional and Rectified Hebrew calendars will match from the present era until Hebrew year 6000.

Note that this list of matching dates shows that the Traditional Hebrew calendar is presently a month late in years 8, 19, 11 of each 19-year cycle, and starting soon (depending on the coefficients adopted for the leap rule and elapsed months expression), year 3 of each cycle will also be a month late.

This 353-year leap cycle is easily tuned to keep the average northward equinox moment close to the start of Nisan for several millennia into the future. The arithmetic details are presented below in the sections discussing the ElapsedMonths function and the isHebrewLeapYear function, respectively. At present the calendar mean year length of this 130/353 lunisolar leap month cycle with progressive molad is almost the same as that of a solar calendar having a 293-year leap cycle with either 71 leap days or 52 leap weeks per cycle.

Don’t confuse the number 353 = years per leap cycle with the number of days in shanah chaserah (שנה חסרה), the deficient year, in which Cheshvan and Kislev each have 29 days.

Features of the Rectified Hebrew Calendar

The rectified Hebrew calendar is a lunisolar calendar which obeys every rule of the traditional (fixed arithmetic) Hebrew calendar except that it replaces the 7 leap months per 19-year Metonic cycle with a much more accurate cycle having 130 leap months per 353 years to substantially reduce the long-term calendar drift with respect to the solar cycle (seasons), specifically the northward equinox (spring equinox of the northern hemisphere), and it also adjusts the molad arithmetic to substantially reduce the long-term calendar drift with respect to the lunar cycle.

The rectified Hebrew calendar employs a progressive molad that tracks the progressively shorter mean lunation interval (from New Moon to New Moon), which is presently almost ³/₅ second or ⁹/₅₀ of a part shorter than the molad interval of the traditional Hebrew calendar. The rectification of the molad intervals determines the calendar mean year, which progressively gets slightly shorter in parallel with the Mean Synodic Month, as shown in this chart 28KB, at the rate of about ³/₂ seconds per 353-year leap cycle or about ¹⁷/₄ seconds per millennium. Whereas the traditional molad originally referred to a meridian of longitude that was midway between the Nile River and the end of the Euphrates River (as explained on my molad of the Hebrew calendar web page), the progressive molad refers directly to the meridian of Jerusalem. The molad adjustment arithmetic automatically shortens the progressive molad interval in parallel with the long-term progressively shorter duration of the actual astronomical Mean Synodic Month.

Like the traditional Hebrew calendar, the rectified Hebrew calendar employs the same fixed month lengths and uses the molad only to determine the date of Rosh Hashanah, contingent on traditionally equivalent Rosh Hashanah postponement rules that automatically adapt to the progressively shorter progressive molad interval.

Although I will present charts showing the long-term alignment of the rectified Hebrew calendar relative to both equinoxes, please note that it is impossible to design any calendar that simultaneously maintains excellent alignment with both of them, because their respective equinoctial years lengths are different and are changing at different rates. Currently the mean southward equinoctial year length is is about 30 seconds shorter and is changing much more rapidly than the mean northward equinoctial year — for details please see my "Lengths of the Seasons" web page at <http://individual.utoronto.ca/kalendis/seasons.htm>.

Comparison Between the Traditional and Rectified Hebrew Calendars

Feature or Attribute	Traditional Hebrew Calendar	Rectified Hebrew Calendar
Years in Leap Cycle:	19 (prime) = Metonic cycle	353 (prime)
Leap Years Per Cycle:	7 (prime)	130 (prime divisors are 2, 5, 13)
Months Per Cycle:	235 (prime divisors are 5 and 47)	4366 (prime divisors are 2, 37, 59)
Calendar Mean Year in 4119 / 5766 (rate of change):	365+24311/98496 days = 365d 5h 55m 25+25/57s (constant mean year, currently about 6 minutes and 25+25/57 seconds too long)	365d 5h 49m 5s / 365d 5h 48m 58s 72KB (–3/2 seconds per 353 years or about –17/4 seconds per 1000 years), see the RectifiedMeanYear function.
Lunar Cycle Synchronization:	Traditional molad for Rosh Hashanah only, originally referred to a meridian of longitude midway between the Nile River and the end of the Euphrates River, but it is drifting later at an accelerating rate with respect to the mean New Moon	Progressive molad for Rosh Hashanah only, refers to the meridian of Jerusalem, essentially drift-free with respect to the mean New Moon.
Calendar Month Lengths:	Fixed except Cheshvan and Kislev (see postponement rules)	Same, except that the postponement rules automatically adapt to the progressively shorter progressive molad interval.
Arithmetic Fixed New Year Day:	Traditional molad of Tishrei (subject to postponements)	Progressive molad of Tishrei (subject to postponements), but date may differ from Traditional due to the progressively shorter molad interval and more accurate leap cycle. From the present era until Hebrew year 6000, matches the Traditional Tishrei in 176 of 235 years (almost 75%).

Sources for Astronomical Algorithms to Validate Calendar Performance

I used the calendrical calculation functions and astronomical algorithms described in "Calendrical Calculations" by Nachum Dershowitz and Edward M. Reingold, third edition published in 2008 by Cambridge University Press. I will use the mnemonic CC3 to refer to that book. Except for a few minor arithmetic functions that are identical to CC3 and acknowledged as such, all calendar function names defined herein are spelled differently from those that appear in CC3, even if the function has equivalent parameters and return value, to avoid any name conflicts.

Rabbi Moshe ben Maimon ("Rambam"), also commonly known by his Greek name, (Moses) Maimonides, wrote a book entitled Hilchot Kiddush haChodesh (title translated as "Sanctification of the New Month" or alternatively as "Sanctification of the New Moon") around the Julian year 1178 or Hebrew year 4938, which is one of the treatises in his Mishneh Torah collection (code of Jewish Law).

Click here to read what Rambam wrote about relying on non-Jewish sources for astronomical calculations 73KB.

I also included some algorithms from "Astronomical Algorithms" by Jean Meeus, second edition, published in 1998 by Willmann-Bell, Richmond, Virginia, USA.

Limitations: The astronomical algorithm employed for solar longitude ignores Neptune, Pluto and all asteroids, based on Meeus' truncation of the VSOP87 planetary theory of Pierre Bretagnon et al, and for lunar position is based on Meeus' truncation of the ELP-2000 semi-analytical lunar theory of Jean Chapront et al. The parabola used to approximate Delta T is based on the assumption that solar days will get 1.75 milliseconds longer each century (for more information about Delta T see this page). Relativistic effects are not accounted for.

What if the Observational Hebrew Calendar is Reinstated?

I am frequently asked "What is the relevance of this rectified Hebrew calendar reform if the observational Hebrew calendar is reinstated by the New Sanhedrin, based on the testimony of two reliable witnesses regarding the first visibility of the new lunar crescent?"

Such observations are only concerned with determining whether the new month starts on the 30th or the 31st day after the start of the previous month. In other words, crescent observations replace the molad, but not the rule for leap years. They have nothing to do with the decision to insert a leap month, therefore nothing to do with correcting the seasonal drift of the Hebrew calendar. According to what Rambam wrote in his treatise cited above, the Sanhedrin had to make the decision to insert a leap month or not well in advance of the equinox, so that pilgrims intending to come to Jerusalem would know when to begin their journey, and was based on prediction of the Tekufat Nisan (spring equinox) moment using either the Tekufat Shmuel or the Tekufat Adda calculation, which are explained on my web page "Rambam and the Seasons".

If the Sanhedrin relied on Tekufat Shmuel then the calendar would drift at the same rate as the Julian calendar, which has a mean year that is about 11 minutes too long per year. If they relied on Tekufat Adda then the calendar would drift at exactly the same rate as our present Hebrew calendar, as explained on my web page "The Seasonal Drift of the Hebrew Calendar", because the mean year of the Tekufat Adda calculation is identical to the mean year of the Hebrew calendar. Although Rambam gave his own method for calculating equinox moments based on solar longitude, and I have confirmed that his method is accurate to within one day for the first 10000 years of the Hebrew calendar (the small residual errors due mainly to his excess rate of advance of aphelion, which he called "apogee" because he thought that Sun orbited Earth, and he was unaware of the lunar tidal slowing of the Earth rotation rate), that method was not available to the Sanhedrin and anyway it involves an extremely prolonged set of calculations. Perhaps they had available to them a calculator like the multi-geared Antikythera Mechanism to guide them, which were produced on the Isle of Rhoads around the 2nd century BC?

Although Rambam listed several agricultural and weather factors that the Sanhedrin might have taken into account in their leap year decision, he wrote that those supplemental factors were rarely invoked, because taking them into account would delay the decision too much.

The Talmud Bavli tractate Eruvin page 56a very briefly mentions that on Tekufat Nisan (spring equinox, in the Hebrew month of Nisan) and on Tekufat Tishrei (autumn equinox, in the Hebrew month of Tishrei) the Sun rises at the middle of the range of sunrise points during the year and sets at the middle of the range of sunset points (for more detail see the beginning of my "Rambam and the Seasons" web page). This method was used to establish the four cardinal directions when surveying a city to calculate the size and orientation of a square that could enclose it, in preparation for setting up an eruv. There is no indication that this method was used for calendrical purposes. Clearly it would not have permitted the decision to be made in advance of the equinox, but it could have been used to monitor the accuracy of the Tekufat Nisan predictions.

Therefore, even if the observational Hebrew calendar is eventually reinstated, the decision whether to make the year leap or not will have to be made independently of observations, either based on modern astronomical polynomials for the mean equinox moment or astronomical algorithms or numerical integration for the actual equinox moment and up-to-date approximations for Delta T to take the variations of the Earth rotation rate into account, or using the very good approximation afforded by the 130/353 fixed leap cycle of the rectified Hebrew calendar. If the 130/353 leap cycle is used as recommended herein then the dates of the observational Hebrew calendar would always agree to within ±2 days with the rectified Hebrew calendar. The unpredictable observational Hebrew calendar would be appropriately used for ritual purposes, especially with regard to activities in the 3rd Temple, because as explained in the Talmud tractate Rosh Hashanah a special sacrifice such as that for Rosh Chodesh (start of month) must be b'zmano (in its "proper time"). On the other hand, the predictable dates of the rectified Hebrew calendar would be more appropriate for civil, commercial, industrial, institutional, and governmental purposes in Israel, particularly where computer systems need to handle Hebrew dates and carry out calendrical calculations.

By the way, Rosh Hashanah on the observational Hebrew calendar ought to land on Sunday, Wednesday, or Friday in 3 out of 7 years, on average. These are ritually inconvenient weekdays that there is a long tradition of avoiding, as explained on my Rosh Hashanah Postponements web page. The Talmud in tractate Rosh Hashanah discusses maneuvers whereby the Sanhedrin would intimidate witnesses or grossly prolong their interviews or accept dubious testimonials just to avoid having Rosh Hashanah land on these inconvenient weekdays. Although the ancient authorities could "get away" with such ploys, they would not be tolerated in the modern era. Therefore it is probably impractical and unrealistic to believe that the observational Hebrew calendar will ever be reinstated.

Fixed Dates — the Rata Die

The computer functions for implementing this rectified Hebrew calendar are designed to convert dates to and from the rata die (ordinal day number, or "fixed date") as described by Dershowitz & Reingold in CC3. The epoch for the rata die is the proleptic Gregorian date Monday, January 1st of the year 1, which was rata die number 1. Such fixed dates serve as a common denominator for interconversion of dates based on any calendar. Relative to that epoch, the Hebrew calendar has a fixed date epoch of –1373427, which was Monday (Yom Sheini), Tishrei 1 of Hebrew year 1. To facilitate interconversion to or from any other calendar, the arithmetic herein will use the fixed dating system of Dershowitz & Reingold in CC3, relative to the proleptic Gregorian epoch. To convert a rata die to or from an ordinal day number relative to the Hebrew calendar epoch, simply add or subtract 1373427 days, respectively.

A convenient internet resource for interconverting dates between a wide range of calendars and the rata die is the Calendrica applet of Dershowitz & Reingold at <http://emr.cs.iit.edu/home/reingold/calendar-book/Calendrica.html>. For example, using the arithmetic presented here, a rectified Hebrew calendar date can be converted to any other calendar supported by the Calendrica applet, via the rata die value for that date, or conversely any date on any other calendar can be converted to a rata die which can then be used with the arithmetic herein to determine the corresponding rectified Hebrew calendar date.

Alternative fixed day numbering schemes are easy to implement, merely by assigning an appropriate numeric value to the Hebrew calendar epoch, the trade-off being the loss of the ability to directly use the fixed day numbers with the Calendrica applet. An obvious choice for Hebrew calendar purposes is to enumerate the days relative to the Hebrew calendar epoch itself, although for most accurate calculation of zmanim (ritually important moments during each day) it would be better to employ a near-present-day epoch. For more information see the discussion of fixed day numbering in the Symmetry454 Arithmetic PDF at <http://individual.utoronto.ca/kalendis/symmetry.htm>. In addition, Kalendis allows the user to choose from several built-in fixed day numbering epochs, including the epoch of the Hebrew calendar, or it can enumerate days relative to any user-selected arbitrary date in the past or future.

Calendrical calculations make frequent use of dividing a number and keeping only the remainder, for example, dividing the rata die by 7 to determine the weekday. Many programming languages have a MOD operator or function intended for this purpose, but in many languages MOD handles negative or real numbers improperly (the MOD operator of Microsoft Visual Basic is defective on both counts). If you have a defective MOD operator or function, or are not sure, use the following as recommended by Dershowitz & Reingold in CC3:

modulus( x, y ) = x – y × floor( x / y )

Not being limited to integer division, the CC3 modulus function also works properly with floating point (real number) parameters provided both the x and the y parameter and the function return value are declared as Double Precision.

Calculation Precision — the Limitations of "Floating Point" Arithmetic

A fixed date that is to represent a day on any calendar is an integer value which represents that date at midnight, and computer program variables used to store and manipulate such fixed dates must be allocated at least 32-bits.

A rata die moment is a date-time value that combines a fixed date integer with a decimal fraction representing the portion of the day that has elapsed (or, for negative moments, prior to the epoch, the portion of the day that has not yet elapsed). All such moments must be stored in variables that support at least Double Precision floating point, because Single Precision is insufficient to resolve specific moments to better than a second when the integer part of the number is relatively large, as is typical of calendar calculations.

I have made every effort to specify coefficients and constants using either exact integers or proper fractions, so that all results can be unambiguously calculated using exact computing engines capable of arbitrary-precision arithmetic, such as Mathematica, or the favorite of Professors Dershowitz & Reingold, the computer programming language "LISP". When a floating point computation does not agree with the exactly calculated result, the exact result must always take precedence.

Some strategies to extend the precision of floating point arithmetic for calendrical calculations include:

• apply calculations separately to the integer and fractional parts of operands
• use quadruple-precision floating point arithmetic, if available
• use arbitrary-precision arithmetic, if available
• carry out calculations using smaller numbers relative to a near-present-day epoch, such as J2000.0 (the astronomical favorite)
• declare constants and coefficients in full precision:
  For example, in Visual Basic 6 "Public Const QuarterDay As Double = 1 / 4" internally assigns only a single precision value to the constant QuarterDay, even though the type of constant is double precision, and the same happens even if "= 1# / 4#" is used. To obtain full precision in that environment the programmer must in this case use "= 0.25". Similarly any floating point constant that can be represented as an exact decimal number is better declared that way rather than using an expression. The way to do this varies between systems.

Copying Formulae or Statements and Pasting into Other Applications

The formulae presented here have been laid out for readability and clarity. In many cases there will be minor problems if the reader copies a formula from this web page then pastes it directly into a computer programming environment, spreadsheet, or mathematics package. This section outlines how to deal with these minor difficulties:

1. In most cases instead of a minus sign I use the "N-dash" character "–", or in HTML "&ndash;" because it is easier to see. Almost all calculating environments will require the user to manually replace all N-dash characters with the normal minus sign, which is a simple hyphen like this "-".
2. I generally avoid using implicit multiplication (operands placed side-by-side without any operator between them). Instead, I use the HTML &times; symbol " × ". Almost all calculating environments will require the user to manually replace all " × ". symbols with an asterisk "*".
3. In a few places I raise a number or a symbol to a power, for example x². Most calculating environments will require the user to manually insert an exponentiation symbol such as "^" or "**", for example "x^2" or "x**2".
4. Where I used numeric scientific notation, for example 1.58 × 10^-10, typical programming environments would need such a number in a format like 1.58*10^-10 or simply 1.58e-10 or 1.58E-10.
5. Fractions can be replaced by floating point constants, but be sure that the values are converted as exactly as possible, always using Double precision or better.
6. There is no computer programming language that uses exactly the statement or operator syntax that I employ herein, although it is quite similar to Microsoft Visual Basic 6 (VB6). I felt at liberty to change the VB6 syntax to make the statements easier to understand for those that have never used VB6. Don't expect to be able to copy the statements of a function verbatim. Program code won't work until the user makes the minor changes to syntactically adapt it to the target programming environment.
7. Any text to the right of the straight apostrophe ' symbol is a free text explanatory comment not required in the program code. Nevertheless, in many places I have inserted comments without any such delimiting apostrophe, where I thought the reader would obviously understand that it is free text.
8. In most cases I haven't specified the type of variable to use for any parameters or return values (eg., boolean, integer, long integer, double, character, string, etc.), because that is system dependent and hopefully obvious from the context.

The Locale in Jerusalem

All calculations that are affected by the chosen locale shall use Jerusalem, specifically 31° 46' 40" North Latitude and 35° 14' 4" East Longitude, Elevation 800 metres.

It is most convenient to work with Universal Time for modern astronomic calculations such as determining the moment of an equinox or actual lunar conjunction, referred to the Prime Meridian (0° Longitude) at Greenwich Observatory, UK. Sunset shall be determined for Jerusalem as a moment in terms of Israel Standard Time, then converted to Universal Time by subtracting 2 hours. To convert from Universal Time to the Jerusalem Mean Solar Time for this locale, add 2 hours 20 minutes and 56 seconds.

Subsequent to this work, I was persuaded that the midpoint between the Nile River and the end of the Euphrates River would be a more appropriate reference meridian, corresponding to the point where the borders of the modern states of Jordan, Iraq, and Saudi Arabia meet, about 4° east of Jerusalem. The Local Mean Time at this Nile-Euphrates Midpoint is 16 minutes ahead of Jerusalem Local Mean Time, which is negligible for the purposes of astronomical evaluations, so I didn't redo that work.

The locale is passed as a parameter to some functions that depend on it, such that the latitude, longitude, elevation, and time zone of the locale are available to the function being called. None of the functions described herein need the locale, but it is useful for sunset and equinox moment calculations used to evaluate calendar performance.

The Hebrew Calendar Mode

The calendar arithmetic documented herein supports multiple modes, for example it can carry out either traditional or rectified Hebrew calendar calculations, depending on the value of the Mode parameter passed to its functions. The Mode parameter need only be passed to functions that actually handle the modes differently. In each case where multiple modes are supported, I will give the logic for the Traditional (probably most familiar) mode first, followed by the Rectify mode.

The values of Mode are based the following enumeration:

Traditional = 1 ' for the traditional Hebrew calendar with traditional molad and 19-year leap cycle
Rectify = 2 ' for the rectified Hebrew calendar with progressive molad and 353-year leap cycle

Of course, since there are only two choices, it would suffice to employ a boolean True or False setting for Mode. It is defined as an enumeration to provide for adding more modes, such as unifying into here the arithmetic of the astronomical Hebrew calendar, which could be useful for historical research or to guide Sanhedrin calendar decisions.

In the implementation suggested herein, I have shown Mode as an explicit parameter that is passed to each function that may require it, but the programmer may prefer to declare Mode as a global variable instead. This will probably be more efficient, in that it avoids passing Mode to functions that use it only pass it to other functions. However, use of a global variable may make program code harder to understand, and there is a risk that one will forget to set the appropriate Mode. Passing the Mode explicitly is more convenient when rapidly switching modes, for example in comparative evaluations or date conversion operations. In addition, this strategy avoids the need for a programming environment that supports global variable declarations.

The Number of Prior Elapsed Months — the ElapsedMonths Function

This function is critical for determining the leap cycle of the calendar and hence its alignment relative to the solar cycle, specifically the northward equinox (spring equinox of the northern hemisphere). Given the Hebrew calendar Mode and any Hebrew year and month number, the ElapsedMonths function computes how many traditional or rectified months have elapsed prior to that month since the epoch of the Hebrew calendar. Its arithmetic depends directly upon the fixed 19-year or 353-year leap cycle. The calling syntax is:

Lunation = ElapsedMonths( Mode, hYear, hMonth )

All fixed leap cycle Hebrew calendar modes require an adjustment of the year number to account for the month numbering which traditionally starts from Nisan, yet the civil year number is incremented at Tishrei. We'll store the adjusted year number in a local variable so as not to risk modifying the given year number in case it was passed by reference rather than by value:

IF hMonth < Tishrei THEN TheYear = hYear + 1 ELSE TheYear = hYear

where the Hebrew months are numbered from Nisan=1 to Tishrei=7 to Adar=12, etc.

The traditional Hebrew calendar employs the 19-year Metonic cycle. In 19 years there are 19 × 12 = 228 regular months, plus there are 7 leap months, for a total of 235 lunar months per cycle:

IF Mode = Traditional THEN

RETURN hMonth – Tishrei + quotient( 235 × TheYear – 234 , 19 )

For example, Cheshvan (8th month) of traditional Hebrew calendar year 5766 = 8 – 7 + quotient( 235 × 5766 – 234 , 19 ) = 1 + quotient( 1354776 , 19 ) = 1 + 71304 = 71305.

The rectified Hebrew calendar employs the more accurate 353-year leap cycle. In 353 years there are 353 × 12 = 4236 regular months, plus there are 130 leap months, for a total of 4366 lunar months per cycle:

ELSE ' Mode = Rectify

RETURN 12 × TheYear – 12 + hMonth – Tishrei + quotient( 130 × TheYear + Δ , 353 )

END IF

where Δ = 138 and determines the long-term equinox alignment, as explained below.
[The symbol to the left of the "=" sign in the line above should be an uppercase Greek delta, otherwise use a more capable web browser!]

I used Δ = 138 for almost all of the astronomical evaluations of the Rectified Hebrew calendar (except where stated otherwise), but later discovered that Δ = 139 has the slight advantage that it inherently and automatically symmetrically distributes the subcycles of the calendar's leap cycle as follows: 9 × 19 + 11 + 9 × 19 = 353 years. That is to say: 9 repeats of a 19-year metonic subcycle (each containing 7 leap years), then it omits one octaeteris (8 year subcycle, including 3 leap years) to truncate the middle subcycle to only 11 years (containing 4 leap years), then another 9 repeats of a 19-year metonic subcycle (each containing 7 leap years) = 353 years (including a total of 130 leap years). This tweak has a negligible impact on the average northward equinox date (about 2 hours), so I didn't repeat the astronomical evaluations.

The partial expression "12 × TheYear – 12" can be combined with the quotient expression to yield this simpler formula:

RETURN hMonth – Tishrei + quotient( 4366 × TheYear – 4098 , 353 )

where 4366 is derived from the total number of months per leap cycle = (12 × 353) + 130, and –4098 is derived by subtracting the total number of regular months from Δ = 138 – (12 × 353).

For example, Cheshvan (8th month) of rectified Hebrew calendar year 5766 = 8 – 7 + quotient( 4366 × 5766 – 4098 , 353 ) = 1 + quotient( 25170258 , 353 ) = 1 + 71303 = 71304.

Note that at the start of Tishrei 5766 the traditional Hebrew calendar was one month behind the rectified Hebrew calendar, because the traditional Hebrew calendar inserted a leap month during the spring of 5765, whereas the rectified Hebrew calendar made 5766 a leap year.

(One might elect not to use the simpler formula, to allow direct experimentation with the Δ value, for example to evaluate its effect on long-term equinox alignment.)

Neglecting the small difference in the lengths of the molad intervals employed, it takes 19 × 353 = 6707 years for a full month difference to accumulate between this improved 353-year leap cycle and the traditional 19-year Metonic cycle. In 6707 years the traditional 19-year cycle has exactly 2471 leap months wereas this 353-year cycle has exactly 2470 leap months. Once per 6707 years there is a period of 353+19–2=370 consecutive years of perfect leap status agreement between the rectified and the traditional Hebrew calendar. The value of Δ sets which year of the leap cycle was the first year at the epoch, determines the average alignment of the calendar with respect to the northward equinox, and determines when the periods of 370 consecutive years of leap status agreement occur.

The Δ value = 138 resets the present era average northward equinox moment to about ³/₄ of a day (midnight) before the Jerusalem sunset that starts the month of Nisan, intended to prevent the equinox from landing after the end of the first day of Passover (Nisan 15). The ideal average equinox alignment needs to be slightly before the start of Nisan because the 353-year cycle mean year is slightly shorter than the present-day northward equinoctial mean year, and we want to prevent the latest equinox moments from occurring on or after the 16th of Nisan in the future. The average southward equinox (autumn equinox for the northern hemisphere) will align on the 10th of Tishrei (Yom Kippur), shifting over future millennia towards the 9th of Tishrei and then to earlier dates, and the latest southward equinox moment in the present era will be on the 25th of Tishrei.

The Δ value can be incrementally changed to shift the equinox alignment in increments of ¹/₃₅₃ of a progressive molad interval, or about 2 hours per step. The average equinox date in Nisan, relative to the moment of sunset that starts the month (a result equal to one is the moment of the Jerusalem sunset at the start of Nisan, zero is the start of the day prior to Nisan, negative numbers are correspondingly earlier days), can be estimated as:

AverageEquinoxDateInNisan = – Δ × ( progressive molad interval) / 353 + ²²⁴/₁₉

As an example taking the case of the recommended Δ = 138 and using the present-day progressive molad interval (³/₅ second or ⁹/₅₀ of a part shorter than the traditional molad interval), the AverageEquinoxDateInNisan = – 138 × ( 29 days + 12 hours + 44 minutes + 1 part – ³/₅ second ) / 353 + ²²⁴/₁₉ ≈ ¹/₄ of a day (midnight), which is about ³/₄ of a day before the sunset that starts the month of Nisan.

Conversely, given a desired average equinox date, the required Δ value can be calculated using the inverse expression, rounded to the nearest integer:

Δ = round( – 353 × ( AverageEquinoxDateInNisan – ²²⁴/₁₉ ) / ( progressive molad interval) )

For example, taking the recommended average equinox alignment of ³/₄ of a day before the Jerusalem sunset that starts the month of Nisan, Δ = – 353 × ( ¹/₄ – ²²⁴/₁₉ ) / ( 29 days + 12 hours + 44 minutes + 1 part – ⁹/₅₀ of a part ) ≈ 137.94, which rounds to 138.

The earliest possible average equinox alignment for the 353 years starting with Nisan of Hebrew year 5766 is about –17 ³/₄ or midnight 18 days before the start of Nisan with Δ = 352, and the latest possible average alignment is at about two hours after noon on the 11th day of Nisan with Δ = 0. There is no reason for choosing either of these extreme values, but they do indicate the relatively wide range over which the equinox alignment is adjustable.

On the 15th of Nisan, ¹/₂ hour after Noon corresponds to nominally 14 ³⁷/₄₈ days after sunset on the 1st of Nisan, that is one half lunar cycle from the start of the month (because the month starts on day one, not day zero). The calendar, however, can't have a leap month length of one half lunar cycle, because the leap month has to have an integer number of days. Like the traditional Hebrew calendar, the rectified Hebrew calendar has a 30-day leap month (Adar Rishon), so the variability of the equinox alignment has to include at least ³⁰/₂ = 15 days before and after the average.

The Talmud Bavli, especially in tractate Sanhedrin page 13 and tractate Rosh Hashanah page 21a, discusses the desired equinox alignment with regard to decisions whether or not to insert a leap month, including a debate as to whether the day of the equinox is the last day of the prior season, or the first day of the new season, but the arguments are astronomically moot because they appear to concern arithmetic determination of the equinox moment rather than the actual astronomical equinox or an equinox determined by observation of the true solar azimuth at sunset (see also the Talmud Bavli azimuthal definition of the seasons — Tekufot — in tractate Eruvin, page 56a).

An astronomically impossible Talmud criterion is the statement that the equinox must occur "during the renewal of the Moon in Nisan", that is during the first half of Nisan when Moon is waxing, rather than during the second half when Moon is waning. This requirement is unattainable because the solar cycle runs independently of the lunar cycle — an actual astronomical equinox moment can occur at any time during a lunar month. The best that can be done is to ensure that about half of the equinox moments occur during the first half of Nisan, but the remainder must occur during the last half of the prior month, which will be either Adar or Adar Sheini. In a leap year the equinox moment must always land in Adar Sheini. In other words, ensuring that the average equinox moment is close to the start of Nisan will ensure that as the years pass the greatest possible number of equinox moments (50%) will occur during the renewal of Moon in Nisan.

Another astronomically impossible Talmud criterion concerns the debate whether the equinox in Tishrei must always occur prior to the 16th or the 20th day of Tishrei. Neither of these is possible, so the argument is again moot, unless the debate concerned intercalation of a second month of Elul, as was the Babylonian practise once per 19-year cycle. There are two astronomic constraints that preclude a leap rule with regard to the equinox in Tishrei. Firstly, the date of Rosh Hashanah is fixed relative to the molad of Tishrei. Therefore, with a day or two leeway, Rosh Hashanah must start 6 lunar months after the start of Nisan = 6 × the molad interval = a bit more than 177 days, which would place the 16th and 20th of Tishrei at about 192 or 196 days after the start of Nisan, respectively. On average in the present era there are about 92+³/₄ days from the northward equinox to the north solstice, and about 93+²/₃ days from the north solstice to the southward equinox, so the total span from the average equinox of Nisan to the average equinox of Tishrei is about 186+²/₅ days. Therefore if the average equinox of Nisan is at the start of Nisan then the average equinox of Tishrei can only be at Yom Kippur on the 10th of Tishrei, with ±¹/₂ month of variation at both equinoxes (in parallel) due to the leap month structure of the calendar. Thus the astronomical equinox of Tishrei must actually range from the last week of Elul through to the 25th day of Tishrei, and there is nothing that can be done to prevent a late equinox in Tishrei as long as the start of Nisan is aligned with its average equinox. The second astronomical constraint is that for the past millennium the length of the southward equinoctial year has been shorter than the northward equinoctial year, and it will continue to get shorter while the northward equinoctial year length remains essentially constant for the next >4 millennia. Therefore there is no way for any fixed arithmetic calendar to simultaneously maintain alignment relative to both equinoxes. Although an astronomical leap day or leap week calendar might be able to average its alignment with both equinoxes, a leap lunar month calendar such as the Hebrew calendar can't possibly align with both equinoxes even using astronomical algorithms.

A superb middle-ground option, although difficult to justify within Jewish Law, would be to align the calendar relative to the north solstice (summer solstice of the northern hemisphere), which only recently entered a 10-millennium era of stability — please see my "Lengths of the Seasons" web page at <http://individual.utoronto.ca/kalendis/seasons.htm>. The ancient Athenian calendar was a lunisolar calendar that started the New Year near the north solstice, although in that era the north solstitial year length was rapidly getting shorter.

For the present era, aligning any fixed arithmetic lunisolar calendar relative to the north solstice is easily accomplished by using a 296-year leap cycle having 109 leap years and a total of 3661 months per cycle. If a progressive molad is used then the calendar arithmetic would have to be arranged differently than presented here to prevent the progressive molad from progressively shortening the calendar mean year. Alternatively a constant molad interval could be used, relative to a future epoch and employing a molad interval that is intentionally slightly too short for the present.

Rather than compromise between the two equinoxes, the northward equinox ought to take precedence, because the first Torah commandment to the children of Israel was recorded as Guard the month of Aviv (barley, referring to the omer offering of the new barley crop) and make a Pesach to the Lord thy God... (Deuteronomy = Devarim chapter 16 verse 1). Although English translations commonly render the word Pesach as Passover, and that is common usage in modern Hebrew, in the language of the Torah the term Pesach refers specifically to the sacrificial Paschal lamb (Korban Pesach), whereas the phrase Chag HaMatzot (Feast of Unleavened Bread) is the Torah term for Passover. The slaughter and sacrifice of the Paschal lamb used to take place during the afternoon of the 14^th of Nisan, starting ¹/₂ hour after Noon, so this could imply that the calendar leap cycle should keep that moment at the earliest opportunity that is after the equinox, within the constraints of the lunar month structure.

If we back-calculate the traditional Hebrew calendar to the days of Hillel ben Yehudah in Hebrew year 4119, however, and evaluate the astronomical equinox alignment at that epoch, the average equinox was near the start of Nisan, extensions of the equinox moment beyond Noon on the 14th of Nisan were not uncommon, and there were even a couple of equinox moments that landed on the 16th of Nisan. Evidently, what was actually done differed from the literal interpretation of the phrase quoted above from Deuteronomy, although this conclusion is strictly valid only if the calendar rules that we have today have not been changed since the days of the original fixed arithmetic calendar that was introduced by Hillel ben Yehudah. Also, in the era of Hillel ben Yehudah they probably used a simple arithmetic determination of the equinox moment (rather than the actual astronomical equinox or an equinox determined by observation of the true solar azimuth at sunset, see "Rambam and The Seasons"):

Traditional Hebrew Calendar Spring Equinox Alignment
in the era of Hillel ben Yehudah (Hebrew year 4119)

Astronomical 21 KB

Tekufat Nisan Shmuel 20 KB

Tekufat Nisan Adda 20 KB

In the above equinox alignment charts it makes no visually appreciable difference if the start of Nisan is taken as the actual sunset moment in Jerusalem or if it is taken as a nominal constant 6 hours before mean solar midnight.

From the Hillel ben Yehudah era charts above it ought to be obvious that Tekufat Nisan of Amorah Shmuel couldn't possibly have been used for establishing the fixed arithmetic traditional Hebrew calendar, because that would have placed many "equinox" moments on days that were well into the second half of Nisan, with the average near the first quarter Moon at the start of the eighth day of Nisan. On the other hand, the more accurate Tekufat Nisan of Rav Adda method yielded spring equinox moments that were very close to the actual astronomical equinox moments (as shown on my web page "Rambam and the Seasons"), yielding average equinox moment aligned at noon on the first day of Nisan, and the latest equinox moments were just a few minutes shy of noon on the second day of Passover (16th day of Nisan). The reference time zone or reference meridian of longitude for the equinox methods and for the Hebrew calendar itself was to the best of my knowledge never specified in the classical or rabbinic sources, not even by Rambam. Many people assume that both refer to Jerusalem, but seems to me more likely that both originally referred to the same meridian as the traditional moladot, which was never at Jerusalem and never will be, as I explained on my "Moon and the Molad of the Hebrew Calendar" web page at <http://individual.utoronto.ca/kalendis/hebrew/molad.htm>. Anyhow, if we simply assume that the reference time zone for Tekufat Adda is the same as that of the Hebrew calendar then the time zone cancels out and we can take Tekufat Adda as a direct indication of the intended equinox alignment. Therefore, aligning the calendar so that the average astronomical equinox moment is at noon on the first day of Nisan would apparently restore the original (pre-drift) alignment that was established in the era of Hillel ben Yehudah.

This choice of noon average equinox alignment (or latest equinox moments shortly before noon on the 16th of Nisan) is quite peculiar from a calendarist's point of view, it is explicitly incompatible with Rambam's assertion that in the days of the observational Hebrew calendar a leap month was inserted if otherwise the equinox would land after the end of the first day of Passover on the 15th of Nisan (Hilchot Kiddush haChodesh, chapter 4, paragraphs 2 and 3), and it is also incompatible with the Talmud Bavli specification that when the equinox lands in Nisan it must be during the waxing portion of the lunar cycle. I suspect that it has something to do with the choice of noon cutoff time for the molad zakein postponement rule for Rosh Hashanah, see <http://individual.utoronto.ca/kalendis/hebrew/postpone.htm>. By contrast, Rambam's assertion would cause the average equinox moment to land at the sunset starting the first day of Nisan, which seems calendrically most appropriate, and would more effectively prevent the Tekufat Nisan of Rav Adda from landing during the waning portion of the lunar cycle in Nisan.

Although the Tekufat Adda method was quite accurate for the northward equinox in the era of Hillel ben Yehudah, it nevertheless is eternally useless for detecting astronomical solar drift of the traditional Hebrew calendar, because the Adda method assumes a constant year length that is exactly equal to the mean year length of the traditional Hebrew calendar, therefore they drift forever in parallel at equal rates relative to the actual astronomical equinox. This means that relative to the Tekufat Adda equinox, the Traditional Hebrew calendar has "zero drift", as shown in this chart 157 KB.

The following charts compare the astronomical northward and southward equinox alignments of the traditional Hebrew calendar, the rectified Hebrew calendar with traditional molad, and the preferred rectified Hebrew calendar with progressive molad:

Astronomical Equinox (northern hemisphere season)	Traditional Hebrew Calendar	Rectified Hebrew Calendar Δ=133, Traditional Molad	Rectified Hebrew Calendar Δ=138, Progressive Molad
Northward (spring)	Nisan 335 KB	Nisan 374 KB	Nisan 372 KB
Southward (autumn)	Tishrei 192 KB	Tishrei 224 KB	Tishrei 224 KB

As the charts show, in the present era both rectified variants reset the average spring equinox to the start of Nisan, with the equinox moments falling no later than the 15th of Nisan (first day of Passover), and with use of the progressive molad the rectified Hebrew calendar maintains enhanced spring equinox alignment that endures for 3 thousand years longer! The reason for this superior longevity is explained in the discussion concerning the RectifiedMeanYear function.

The traditional molad variant aligns the equinox optimally using a smaller Δ value, due to its longer molad interval and hence longer mean year length. This is the only evaluation that will be presented for the traditional molad variant, because the progressive molad offers compelling advantages.

Although the rectified Hebrew calendar Nisan charts both show an "accelerating drift after...", even with use of the traditional molad the rectified Hebrew calendar won't drift as late as the traditional Hebrew calendar has drifted today until around Hebrew year 16000, and with use of the progressive molad the calculations predict that it won't drift as late until Hebrew year 19000!

The above rectified Hebrew calendar charts show a switchover month of Nisan 5766, because at the time of writing that is the next available rectified Hebrew month that will exactly match the traditional Hebrew month. On average, the traditional Hebrew calendar is now 7 to 8 days later than its original equinox-relative alignment, with the average equinox moment almost 6 days before the Jerusalem sunset at the start of Nisan. It is impossible, however, for any individual Hebrew date to be "7 days late", because months are constrained to start close to the molad moment. The only possibilities in the present era are that the traditional Hebrew calendar is either one month late (almost 20% of months), or else it agrees with the rectified Hebrew month (more than 80% of months). In most cases when they agree on the month they also agree on the date within the month, although due to slight differences arising from the progressive molad it is possible for the calendars to disagree on the Rosh Hashanah postponement even when they agree on leap status, thus occasionally introducing ±2 days of variance. Nevertheless, the proportion of perfectly matched months having identical dates is currently almost 73% of months, which will afford many opportunities to switch from the traditional Hebrew calendar to the rectified Hebrew calendar without the nuisance of any missing or duplicated dates.

Click here for a list of the rectified – traditional date differences for the Hebrew years 5766 to 6000.

I was asked how accurately are we able to calculate the moment of an astronomical equinox that occurred back in the era of Hillel ben Yehudah? Using modern astronomical algorithms an equinox moment in terms of atomic time should be accurate to within a few minutes. However some uncertainty exists because calendars work in terms of mean solar time, not atomic time, which means that changes in the Earth rotation rate have to be taken into account. In the short term the Earth rotation rate fluctuates irregularly and unpredictably, but the long-term trend is towards progressively longer days. We have no actual observations of the Earth rotation rate going back so far, of course, but based on published analyses of historically well-documented solar and lunar eclipses, formulae for approximating the changes in the Earth rotation rate have been published. As mentioned above, the formula that I use for this purpose is based on an allowance for solar days growing longer by 1.75 milliseconds each century. Other slightly different formulae have been proposed, and although the true value is unknown it is probably well within 25% of this figure. The Delta T value computed by Kalendis for Rosh Hashanah 4119 on the traditional Hebrew calendar is less than 2 hours, so if that is in error by no more than 25% then the uncertainty of an equinox moment computed for that error is less than 25% of that, or within better than 30 minutes. This degree of accuracy is obviously adequate for calendrical purposes, and in particular is much better than using any of the contemporary traditional simple arithmetic equinox calculations or even Rambam's most accurate solar longitude method.

Is it a Hebrew Leap Year?

Given any Hebrew year number, the isHebrewLeapYear function returns TRUE if the given year has has 13 months, or FALSE if it is a regular year with only 12 months, depending on the Hebrew calendar Mode. It allows the leap status of any year to be determined as simply and quickly as possible. The calling syntax is:

isLeap = isHebrewLeapYear( Mode, hYear )

IF Mode = Traditional THEN ' traditional Hebrew calendar 19-year Metonic cycle

RETURN modulus( 7 × hYear + 1, 19 ) < 7

This calculation multiplies the Hebrew year number times the number of leap years per cycle (7) then adds 1, then divides by the number of years per cycle (19), and if the remainder is less than the number of leap years per cycle (7) then it is a leap year.

For example, for 5765: modulus( 7 × 5765 + 1 , 19 ) = modulus( 40356, 19 ) = 0, which is <7 so 5765 was a traditional leap year, whereas for 5766: modulus( 7 × 5766 + 1 , 19 ) = modulus( 40363, 19 ) = 7, which is not <7 so 5766 is a traditional regular year.

ELSE ' Mode = Rectify ' rectified Hebrew calendar 353-year leap cycle

RETURN modulus( 130 × ( hYear + 1 ) + Δ, 353 ) < 130

END IF

By adding the number of leap years per cycle to Δ = 130+138 = 268, the Rectify expression simplifies to:

RETURN modulus( 130 × hYear + 268, 353 ) < 130

For example, for 5765: modulus( 130 × 5765 + 268 , 353 ) = modulus( 749718, 353 ) = 299, which is not <130 so 5765 was a rectified regular year, whereas for 5766: modulus( 130 × 5766 + 268 , 353 ) = modulus( 749848, 353 ) = 76, which is <130 so 5766 is a rectified leap year.

The logic of the simplified Rectify calculation is the same as the logic for the Traditional 19-year cycle, only differing in the numeric constants employed.

Hebrew calendar leap years are the 2nd or 3rd year after the previous leap year, at intervals that are as uniformly spread as possible. Therefore, when generating a leap year list, after each leap year is encountered the next year can be skipped to save a small amount of processing time, because that next year can't possibly be a leap year:

FOR hYear = StartYear TO EndYear

IF isHebrewLeapYear( Mode, hYear ) THEN

PRINT hYear ' or do whatever you want with this leap year number

hYear = hYear + 1 ' skip the next year because it can't possibly be a leap year too

END IF

NEXT hYear

---

Click here to see a list of rectified Hebrew calendar leap years (using the progressive molad).

---

Patterns in the Intervals Between Leap Years

The average interval between leap years is the number of years per leap cycle divided by the number of leap years per cycle. For the traditional Hebrew calendar that is ¹⁹/₇ = 2+⁵/₇ ≈ 2.714286 years, whereas for the rectified Hebrew calendar it is ³⁵³/₁₃₀ = 2+⁹³/₁₃₀ ≈ 2.715385 years. It is not, however, valid to directly compare their average leap year intervals, because their calendar mean years are different and, due to the molad rectification, discussed below, the rectified Hebrew calendar mean year length gets progressively slightly shorter as the years pass.

Over a few centuries only fractional differences accumulate between the traditional and rectified Hebrew calendars. In 353 years the rectified cycle has exactly 130 leap months, whereas the traditional cycle has an average of 130+¹/₁₉ leap months. Thus it takes 19 × 353 = 6707 years for the traditional Hebrew calendar to permanently fall behind the rectified by one full month. In 6707 years the traditional 19-year cycle has exactly 2471 leap months whereas the rectified 353-year cycle has exactly 2470 leap months.

Analysis of the patterns in the intervals between leap years explains why this happens:

In each cycle of the traditional Hebrew calendar the leap years are the 3rd, 6th, 8th, 11th, 14th, 17th, and 19th years. The intervals between these leap years, counting from the beginning of the cycle are 3 3 2 3 3 3 2 years, repeating for each cycle. That is the most uniform spread of 7 leap years that is possible in a 19-year cycle (shifting the pattern left or right doesn't change the spread, nor the calendar mean year, provided that the shifted pattern repeats for each cycle). Those intervals can be arithmetically grouped into a subcycle of 3+3+2 = 8 years and a subcycle of 3+3+3+2 = 11 years. Thus the traditional 19-year leap cycle has an 8-year subcycle (historically known as an octaeteris) alternating with an 11-year subcycle, repeating for each cycle.

The mean year of the 8-year subcycle (octaeteris) equals the number of months in the subcycle multiplied by the traditional molad interval, divided by 8 years:

= ( 8 × 12 + 3 ) × MoladInterval / 8

= 99 × MoladInterval / 8 = 365 + ¹⁰¹⁶³/₂₃₀₄₀ days = 365 days 10 hours 35 minutes 11+¹/₄ seconds

Thus the mean year of the 8-year subcycle (octaeteris) is much longer than the mean northward equinoctial year length.

The mean year of the 11-year subcycle equals the number of months in the subcycle multiplied by the traditional molad interval, divided by 11 years:

= ( 11 × 12 + 4 ) × MoladInterval / 11

= 136 × MoladInterval / 11 = 365 + ³⁷⁶¹/₃₅₆₄₀ days = 365 days 2 hours 31 minutes 57+¹⁹/₃₃ seconds

Thus the mean year of the 11-year subcycle is much shorter than the mean northward equinoctial year length of about 365 days plus 5 hours 49 minutes and 0 seconds.

The mean year of the full 19-year cycle, however, is intermediate between these two extremes:

= ( 19 × 12 + 7 ) × MoladInterval / 19

= 235 × MoladInterval / 19 = 365 + ²⁴³¹¹/₉₈₄₉₆ days = 365 days plus 5 hours 55 minutes and 25+²⁵/₅₇ seconds

Nevertheless, the mean year of the full 19-year traditional Hebrew calendar leap cycle is more than 6 minutes and 25 seconds too long, relative to the mean northward equinoctial year.

The leap year interval patterns of the rectified Hebrew calendar are almost identical, the only difference being that once per 353-year cycle an 11-year subcycle occurs without an accompanying 8-year subcycle. The full pattern is an 11-year subcycle plus 18 of the traditional 19-year subcycles, repeating forever. As the 11-year subcycle has a shorter mean year than the omitted 8-year subcycle, its insertion shortens the mean year length of the full 353-year cycle:

[ ( 11 × 12 + 4 ) + 18 ( 19 × 12 + 7 ) ] × MoladInterval / 353

= 4366 × MoladInterval / 353 = 365 + ^1109039/_4574880 days = 365 days plus 5 hours 49 minutes and 5+²⁵/₁₀₅₉ seconds

using the traditional molad interval, yielding a mean year that is only 5 seconds too long per year. Thus we see that once per 353-year cycle its pattern of leap year intervals slips ahead of the traditional 19-year cycle by 8 years. Therefore, the maximum number of consecutive years for which the leap year intervals of the 19- and 353-year cycles can match perfectly equals the last 9 years of an 11-year subcycle, plus 18 consecutive 19-year subcycles, plus the initial 11-year subcycle of the next 353-year cycle, plus the first 8 years of the first 19-year subcycle of that next 353-year cycle, for a total of 9+(18*19)+11+8=370 years of perfect agreement.

The position in history of the 370-year peak of perfect leap status agreement is determined by the Δ value used for the elapsed months calculation. Using the recommended value of 138 for the rectified Hebrew calendar with progressive molad, the first such 370-year sequence occurred from Hebrew years 4806 through 5176. Obviously that 370-year period is a curiosity that is of no concern for the present era or the future. The next 370-year matching sequence will start 6707 after the first = 4806+6707 = Hebrew year 11513, which will be too far into the future to be of any interest. The Δ value can be appropriately adjusted to optimize equinox alignment relative to Nisan, but there is no merit in adjusting it for the sake of consecutive years of leap status agreement.

The progressive molad interval gets progressively shorter, and if we use its present era length of about ³/₅ second shorter than the traditional molad interval, then we obtain that the mean year of the 353-year rectified leap cycle is currently:

= 4366 × ( MoladInterval – (³/₅) / 86400 ) / 353 = 365 + ^1109039/_4574880 days ≈ 365 days plus 5 hours 48 minutes and 57.6 seconds

yielding a mean year that is only about 2.4 seconds too short per year in the present era.

The omission of the 8-year subcycle is not by design, and it doesn't increase the calendar's "equinox jitter". It is simply a natural consequence of spreading the leap years of the 353-year cycle as uniformly as possible, generating a repeating pattern that is predictable. The pattern of intervals between leap years is just an observation made after-the-fact. Nevertheless, its recognition does lead to the prediction of other longer and shorter leap cycles:

This Microsoft Excel "Leap Month Cycles" spreadsheet 30KB shows the grouping of leap year interval subcycles for the a variety of leap month cycles, including the traditional and rectified leap cycles as well as some cycles that have intermediate or shorter mean years. (This spreadsheet is compatible with LibreOffice CALC.) It shows that a series of cycles can be derived by inserting the 11-year subcycle progressively more often, generating shorter and shorter calendar mean years. Such shorter cycles are not particularly useful today, but in the very distant future it will be necessary to switch to the shorter Feldman cycle (which has one fewer 19-year subcycle) and later the "Future" cycle (another 19-year subcycle dropped), in order to compensate for the progressively shorter mean northward equinoctial year length. For comparison, a present era north solstice cycle is also shown.

Talmudic Temporal Time (TTT)

As presented here, the moment of either the traditional or progressive molad is expressed in terms of the rata die + 6 hours, which is the traditional "Talmudic Temporal Time" (as I call it), counting the hours since the prior sunset, and the weekday is given directly by:

Weekday = modulus( floor( AnyMolad ), 7 ) + 1

where Yom Rishon = 1 (Sunday) through to Yom Shabbat = 7 (Saturday).

For comparison with the moment of the mean or actual lunar conjunction, or with the CC3 molad function, subtract six hours (¹/₄ day) to convert the traditional or progressive molad moment from Talmudic Temporal Time to Civil Time (counting the hours from midnight).

The MoladMoment Function

The MoladMoment function returns the moment of the traditional or progressive molad, depending on the specified Hebrew calendar Mode. In both cases it computes the moment of the traditional molad in the traditional manner, but if Mode = Rectify it subtracts the MoladAdjustment (discussed in the next section, below). The calling syntax is:

ThisMolad = MoladMoment( Mode, Lunation, Offset )

where, if not already known, Lunation = ElapsedMonths( Mode, hYear, hMonth )

The Lunation is passed as a parameter rather than requiring the MoladMoment function to calculate it, so as to afford an extra degree of control and to eliminate some unnecessary calculations.

As a control example, if one wished to experiment with the progressive molad applied to the traditional Hebrew calendar, one could use Lunation = ElapsedMonths( Traditional, hYear, hMonth ) to get the correct Lunation number for the 19-year cycle, then use ThisMolad = MoladMoment( Rectify, Lunation ) to get the progressive molad for that month of the traditional Hebrew calendar. Alternatively, if one wished to experiment with the traditional molad applied to the rectified Hebrew calendar, use Lunation = ElapsedMonths( Rectify, hYear, hMonth ) to get the correct Lunation number for the 353-year cycle, then use ThisMolad = MoladMoment( Traditional, Lunation ) to get the traditional molad moment for that month of the rectified Hebrew calendar.

As an example of reducing unnecessary calculations, the HebrewNewYear function only needs to calculate the Lunation number by calling ElapsedMonths once, then if it subsequently needs to check the prior or next molad of Tishrei the corresponding Lunation number is just a simple offset (–13 or +12) from the number it already has.

The Offset parameter is double precision and represents the number of days (or fraction of a day) to be added or subtracted from the molad moment before returning its value, for example:

• Plus ¹/₄ day Offset implements the Gauss (Gauß) shortcut in Rosh Hashanah postponement rule processing (see the HebrewNewYear function)
• Zero Offset returns the molad moment in the traditional manner, counting hours from sunset, not midnight, to be used for announcing the moment of the molad in synagogues on the Shabbat prior to Rosh Chodesh (sabbath prior to the start of a new month)
• Minus ¹/₄ day Offset returns the molad moment in terms of civil time, counting hours from midnight, not sunset
• Minus 8 hours and 21 minutes Offset (= ¹⁶⁷/₄₈₀ of a day) returns the progressive molad moment in Universal Time instead of Jerusalem Mean Solar Time (this includes the 6 hours to convert the moment to civil time as above, plus 2 hours and 21 minutes because Jerusalem is that amount of time ahead of Greenwich) [there is no valid Offset which can do the same for any traditional molad moment]. As a Universal Time moment one can relate it directly to an astronomical event computed in Universal Time (such as the actual lunar conjunction), or one can convert it to any desired time zone simply by adding the appropriate number of hours relative to Greenwich, optionally adjusting for Daylight Saving Time if applicable.

The least time division component of the MoladMoment is not the second, but rather ¹/₂₅₉₂₀ day = 1 chelek or "part" = ¹/₁₈ minute = ¹⁰/₃ seconds (see my web page "Why Divide Hours into 1080 Parts?"). The traditional molad moment is calculated using an exact integer number of parts. The progressive molad moment includes a mean astronomical adjustment that is rounded to the nearest part. It is impossible to always exactly represent the number of parts as a floating point fraction of a day because ¹/₂₅₉₂₀ of a day has 6 decimal points and then a 9-digit repeating sequence = 0.000038580246913... , so if you want to know exactly how many parts are contained in a molad moment, extract the decimal fraction from the floating point value, multiply that fractional value by the number of parts per day (PartsPerDay = 25920), and then round it to the nearest part:

ExactNumberOfParts = floor( PartsPerDay × ( MoladMoment – floor( MoladMoment ) ) + 0.5 )

The MoladMoment function starts by computing the moment of the traditional molad corresponding to the given Lunation number, including any specified Offset. To avoid the limitations of floating point arithmetic, it calculates the number of parts separately from the number of days:

MoladMoment( Mode, Lunation, Offset ):

Parts = PartsAtEpoch + Lunation × MoladIntervalParts

where PartsAtEpoch = ⁵/₂₄ + ²⁰⁴/₂₅₉₂₀ = ⁵⁶⁰⁴/₂₅₉₂₀ = ⁴⁶⁷/₂₁₆₀ = 0.2162037...

and MoladIntervalParts = 12 hours 793 parts = ¹²/₂₄ + ⁷⁹³/₂₅₉₂₀ of a day = ¹³⁷⁵³/₂₅₉₂₀ of a day = exactly 13753 parts.

TraditionalMolad = Lunation × MoladIntervalDays + Parts / PartsPerDay + Offset + HebrewEPOCH

where HebrewEPOCH = –1373427, which was the rata die of the first day of Tishrei in Hebrew year 1, corresponding to the 7th of September, 3760 BC on the proleptic Gregorian calendar (assuming that there was a year "zero"), or the 7th of October 3761 BC on the proleptic Julian calendar (assuming that there was no year "zero").

and MoladIntervalDays = 29 days

Later the combined value will be of use: MoladInterval = 29 days 12 hours 793 parts
= 29 days 12 hours 44 minutes 1 part = MoladIntervalDays + MoladIntervalParts,
which is the traditional MoladInterval, and was equal to the length of the Mean Synodic Month (MSM) in the era of the Maccabees.

Note that TraditionalMoladEpoch = PartsAtEpoch + HebrewEPOCH.

This is the epoch traditionally employed for the molad calculation, also known as Molad Tohu or the Molad of Chaos, so-called because it is traditionally regarded as an event that was prior to Creation. Reducing the fraction ²⁰⁴/₂₅₉₂₀ to ¹⁷/₂₁₆₀ would obscure the fact that it represents 204 parts. By contrast, the progressive molad epoch, given below, was 10 hours and 14 minutes earlier.

For example, taking the ElapsedMonths( Rectify, 5766, Cheshvan ) = 71304 from above, the traditional molad moment for that Lunation number was 732222.700462963. The fraction corresponds to 16 hours 48 minutes and 12 parts, which we take as the elapsed time since sunset at the beginning of that Hebrew day. Discarding the fraction, the weekday = modulus( 732222 , 7 ) + 1 = 1 + 1 = 2 = Yom Sheini (Monday). This Lunation number on the traditional Hebrew calendar corresponds to the molad of Tishrei 5766.

If one prefers to work with fractions instead of decimal numbers, then that molad moment was at exactly ^1581601033/₂₁₆₀ = 732222+¹⁵¹³/₂₁₆₀.

In the last step of the MoladMoment function, the molad adjustment is subtracted only for the progressive molad:

IF Mode = Rectify THEN RETURN TraditionalMolad – MoladAdjustment( Lunation ) ELSE RETURN TraditionalMolad

The MoladAdjustment function is discussed in the next section below. It returns a mean astronomical adjustment to be applied to the traditional molad moment such that after adjustment the progressive molad moment will correspond to the moment of the actual secular mean lunar conjunction + 6 hours, referenced to the meridian of Jerusalem, rounded to the nearest part. This means that a clock in Jerusalem that has been set to local mean solar time would indicate the calculated progressive molad time, less 6 hours, at the moment of the mean lunar conjunction. (The word secular, derived from the Latin saeculum, in this context refers to a variation that spans centuries, that is the progressively shorter mean synodic month).

The secular change of the length of the mean synodic month does contain a small periodic variation component that spans many millennia, due to the cyclic variation of the Earth axial tilt (obliquity), although for the next 8 millennia this variation will be negligible. This is explained on my "Length of the Lunar Cycle" web page at <http://individual.utoronto.ca/kalendis/lunar/>.

For example, taking the ElapsedMonths( Rectify, 5766, Cheshvan ) = 71304 from above, the progressive molad moment was about 732222.6162. The fraction corresponds to 14 hours 47 minutes and 6 parts, which is conventionally taken as the elapsed time since sunset at the beginning of that Hebrew day, which, as above, was Monday.

The MoladAdjustment Function

Although the rectified Hebrew calendar arithmetic can be used with traditional molad arithmetic, if a progressive molad is employed instead then the calendar will be able to "hold on" to the northward equinox for much longer and will better track the actual secular mean lunar conjunctions.

The progressive molad interval changes by only –¹/_3164169060 of a mean solar day per month (approximately –27 ¹/₃ microseconds or –⁴¹/₅ "microparts" per month), yet this is sufficient to compensate for the combination of changes in the mean duration of the lunations and the Earth rotation rate. In terms of Atomic Time, the Mean Synodic Month (MSM) is getting longer because tidal forces are accelerating Moon further away from Earth at the mean rate of about 38 mm per year. However, Earth's rotation rate is slowing down more significantly, also due to tidal forces, so that in terms of mean solar days, which are all-important for calendar calculations, the net effect is that the MSM is actually getting shorter. In other words, tidal forces result in the transfer of angular momentum from Earth to Moon, and since the radius of Earth is much shorter than the radius of Moon's orbit, Earth is slowing down more than Moon is slowing down, even though the mass of Earth is about 81 times greater. The net result is that the mean interval from New Moon to New Moon gets steadily shorter relative to the mean solar day.

The progressive molad equals simply the traditional molad minus a molad adjustment. The MoladAdjustment function deliberately makes no attempt to account for short-term periodic differences between the molad and the actual lunar conjunctions, even though taking at least the predominant periodic changes into account could significantly reduce the variations between the progressive molad and the actual New Moon. For example, with relatively simple arithmetic the periodic variations due to lunar orbital eccentricity, lunar perigee advance, Earth orbital eccentricity, and Earth perihelion advance could be partially accounted for, so that the progressive molad (less 6 hours) could fall within ±4 hours of the actual lunar conjunction. Such arithmetic "heroics" would go far beyond the traditional Hebrew calendar requirements, and all of the accounted-for lunar cycle variability would be transferred into the calendar arithmetic, causing the calendar to become less uniformly regulated. In addition, maintaining the long-term accuracy of such periodic adjustments would be problematic, without resorting to the complexity and limited predictability of astronomical algorithms.

This Traditional Molad minus Actual New Moon 184 KB chart illustrates the major periodic variations of the duration of the lunar cycle, including the short-term variations repeating at intervals of about 412 days (almost 14 lunar months) due to the advance of the lunar orbital perigee, medium-term variations repeating at intervals of about 8.85 years (almost 109.5 lunar months) due to the advance of the lunar orbital perigee by 360° with respect to the Earth orbital perihelion, and long-term variations repeating at intervals of about 184 years (almost 2277 lunar months) due to the advance of the lunar orbital nodes by 180° with respect to the Earth orbital perihelion. For an excellent explanation, see "Chapter 4: The Duration of the Lunation" on pages 19-31 in "More Mathematical Astronomy Morsels" by Jean Meeus, published in 2002 by Willmann-Bell, Inc., Richmond, Virginia.

My higher-resolution charts are similar to those shown in Meeus' chapter 4, but the graph axes differ. For the x-axes the Meeus charts use Gregorian year numbers, whereas mine use lunar cycles elapsed since the Hebrew calendar epoch, with vertical gridlines corresponding to the periodic repeat intervals. For the y-axes the Meeus charts are all in terms of ephemeris time (based on 86400 atomic seconds per day) whereas mine are in terms of contemporaneous mean solar hours. The traditional molad chart shows an average of +2 hours difference in the present era (Lunation ≈ 71307), ranging from 12 hours early to 16 hours later than the actual lunar conjunction (a 28-hour range), and a long-term accelerating lateward drift is evident on the third chart, to be accounted for below.

This chart shows a statistical analysis of the duration of the lunation 70 KB, expressed as cumulative percentiles for past, present and future eras. The median duration (50th percentile) is about 29 days 12+¹/₂ hours. The shortest lunations are slightly longer than 29 days 6+¹/₂ hours, and the longest lunations are almost 29 days 20 hours. Although the actual range between the longest and shortest lunations is less than 13+¹/₂ hours, each series of lunations that occur the vicinity of Earth's orbital perihelion tend to be long, and each series of lunations near Earth's orbital aphelion tend to be short, thus each such series adds up to a larger total deviation relative to either the traditional molad moment or the astronomical mean lunar conjunction.

Starting from conjunction with Sun, after Moon has completed one full orbit with respect to the distant stars it is not yet back into conjunction with Sun, because during that lunar month Earth moves in its orbit and therefore the apparent position of Sun changes against the background of stars. Moon must continue in its orbit for another 2 days and a few hours to get back into conjunction with Sun. The time required for Moon to travel along that last extra arc segment varies with Moon's rate of motion (distance from Earth) and also depends on Earth's rate of motion (distance from Sun). This chart shows a statistical analysis of the lunar sidereal revolution 60 KB (time for full lunar orbit with respect to the distant stars). The shortest sidereal revolutions currently take about 27 days 5 hours and 20 minutes, and the longest take about 27 days 11 hours and 15 minutes, so the total variability spans almost 6 hours in the present era. Thus the last extra segment that Moon must move through to get back into conjunction accounts for about half of the variability of the duration of the lunation (conjunction to conjunction). Variability of the sidereal revolution increases with its duration: the 50% of revolutions that are shortest vary over a range of only 2 hours, whereas the 50% of revolutions that are longest vary over a 4-hour range.

This Progressive Molad minus Actual New Moon 121 KB chart shows an average of zero difference between the progressive molad and the actual new moon, and a flat-line horizontal long-term trend. The progressive molad employs a simple mean secular adjustment (to within ±14 hours of the actual lunar conjunction in the present era), in other words ignoring all of the periodic variations in the duration of the lunations (illustrated above) because this suffices to restore the molad moments to their original relationships as existed in the era of Hillel ben Yehudah, with the enhancement of shifting the molad reference meridian to Jerusalem. For more information about the drift of the traditional molad with respect to the actual lunar cycle, see my web page "The Molad of the Hebrew Calendar" at <http://individual.utoronto.ca/kalendis/hebrew/molad.htm>.

The up-going zero crossings of each 14-month cycle are associated with proximity of the lunar orbital perigee to the lunar conjunction, whereas the down-going zero crossings occur when the lunar orbital apogee is close to the lunar conjunction.

Herein I will detail the methods used to arrive at the progressive molad arithmetic, to allow others to reproduce the work, to convince the reader of their validity, and to allow future recalculation to even greater accuracy, if deemed desirable.

Due to the substantial periodic variability of the lunar cycle, any study comparing the traditional molad to the actual lunar conjunction could be statistically biased if the study interval spanned any arbitrary range of dates. To minimize such bias, I searched for a widely separated pair of solar eclipses occurring at the same point in the solar cycle (same solar longitude) with Moon at its orbital perigee. According to Jean Meeus, the author of the astronomical algorithms that I employ, those algorithms are most accurate within ±3000 years from the present era, so I limited my eclipse search to well within that range of years. Furthermore, I wanted the starting eclipse to have been prior to the era of Hillel ben Yehudah, and the ending eclipse to be at least one millennium beyond the present era. Taking the starting eclipse as the first data point, I took the last data point as the lunation prior to the ending eclipse. I constrained the search to find longitudes of the lunar perigee and ascending node which were within ±15° of the lunar longitude at the moment of the eclipse. The following table summarizes the two selected eclipses:

Solar Eclipses Selected for the Molad Perigee Eclipse Study

	Starting Solar Eclipse	Ending Solar Eclipse
Calendar date (at prime meridian)	Monday, May 23, 141 AD (Julian)	Tuesday, May 20, 3530 AD (Gregorian)
Traditional Hebrew calendar date	Yom Sheini, 29 Iyar 3901	Yom Shlishi, 29 Iyar 7290
Date Description	≈ 2 centuries before the era of Hillel ben Yehudah, ≈ 1 6/7 millennia before the present era	≈ 1 1/2 millennia after the present era Total of 3389 years
Julian Day number	1772700.854	3010505.238
Rata Die number (CC3 moment)	51276.35431	1289080.738
Lunation number (from Hebrew Calendar epoch)	48245	90161
Saros Series Number	59	201
Solar and Lunar Longitude	60°	60°
Lunar Perigee Longitude	54.3°	71°
Lunar Ascending Node Longitude	73.1°	46.5°
Earth surface path of eclipse shadow	Grazed the far south Indian Ocean in the morning.	Will graze western Alaska shortly after sunrise.

All of the above longitudes are referred to the ecliptic, which is the plane of the solar system or annual path of the center of Sun in the sky as seen from Earth. The solar longitude of the selected eclipses corresponds to a seasonal point that is ²/₃ of the way from the northward equinox to the north solstice, in other words approximately the beginning of the third month of spring in the northern hemisphere.

The study spanned about 1237804.4 mean solar days, 41916 synodic months, 45487 draconic months, 44922 anomalistic months, 3571 draconic years (eclipse years), and 188 Saros cycles or 62+²/₃ Triple Saros cycles.

For this eclipse-to-eclipse study I computed the difference, expressed as the fraction of a day, obtained by subtracting the actual lunar conjunction moment (calculated in terms of Jerusalem mean solar time using astronomical algorithms) from the traditional molad moment (less 6 hours) for Lunation = 48245 to 90160, inclusive, a total of 41916 synodic months over 3389 Hebrew years. I then used Mathematica version 5 to find the best fit curve to the difference as a function of the Lunation number using least-squares regression, which yielded a quadratic equation. Since the vertex of the quadratic (Lunation number at minimum difference) is of special significance for this study, I obtained the quadratic expression in a format which makes the coordinates of the vertex intuitively obvious:

f(x) = a ( x – h )² + k

where h is the Lunation number at the minimum difference, and k is the minimum difference (fraction of a day) at that Lunation number. The coefficient values computed by Mathematica were a = 1.5801936955469543 × 10^-10, h ≈ 50834.4, k ≈ 0.018173.

Taking Lunation = 50834 as the vertex of the parabola, the point where the traditional molad moment was closest to the actual mean lunar conjunction moment was at the molad of Tishrei, 4111, which was in the era of Hillel ben Yehudah. At that point the minimum difference was 1440 × k = 26 minutes and 3 parts ahead of Jerusalem mean solar time. Ignoring the 3 parts, the 26-minute minimum difference implies that the traditional molad reference meridian was 360° × ²⁶/₁₄₄₀ = ¹³/₂ = 6° 30' east of the meridian of Jerusalem, which is mid-way between Israel and the former Babylonia. A very close fractional approximation for coefficient a ≈ ¹/_6328338120. With these coefficient simplifications the quadratic equation, which represents an adjustment to subtract from the traditional molad moment to yield the actual mean lunar conjunction moment becomes:

MoladAdjustment( Lunation ) = ¹/_6328338120 ( Lunation – 50834 )² + ²⁶/₁₄₄₀

For example, MoladAdjustment( 71304 ) = ¹/_6328338120 ( 71304 – 50834 )² + ²⁶/₁₄₄₀ = ^355521707/_4218892080 of a day = 2h 1m 21s.

This chart 908KB depicts the difference between the traditional molad and actual New Moon moments for the lunations of the eclipse-to-eclipse study. The MoladAdjustment is superimposed in the foreground as a thick red curve (after multiplying by 24 to convert it from fraction of a day to the hours scale of the chart's y-axis).

This chart 908KB depicts the difference between the progressive molad and actual New Moon moments for the lunations of the eclipse-to-eclipse study. The MoladAdjustment straightens out the curvature and shifts the molad reference meridian to Jerusalem mean solar time, nicely centering the periodic variability of the lunar cycle above and below the thick red zero difference line.

These Molad Differences 109 KB charts for the first 130,000 lunations of the Hebrew calendar (to Hebrew year 10510) graphically depicts the absolute difference in hours between the traditional and progressive molad moments in the top chart. The difference reached a minimum of almost 26 minutes in the era of Hillel ben Yehudah and today the traditional molad moments are an average of just over 2 hours late, with the drift rate accelerating. There was a 10-hour difference at the calendar epoch, and there will be a larger and accelerating difference in the future. Converting the 2 hour molad drift to a meridian longitude difference, it is 360° × ²/₂₄ = 30° E of Jerusalem, which at the same latitude is nearest to Qandahar, Afghanistan! The bottom chart depicts the relative difference in seconds between the progressively shorter progressive molad interval and the fixed traditional molad interval, with the present day 2-hour molad adjustment accounted for by the yellow triangle area. The straight trend line crosses zero in the era of Hillel ben Yehudah, and today the progressive molad interval is almost ³/₅ second or ⁹/₅₀ of a part shorter.

The Progressively Shorter Progressive Molad Interval

The Mean Synodic Month (MSM) is simply given by the difference between the progressive molad moments of two consecutive lunations:

MeanSynodicMonth( Lunation ) = MoladMoment( Rectify, Lunation + 1 ) – MoladMoment( Rectify, Lunation )

Substituting in the underlying arithmetic, this function algebraically simplifies directly to:

MeanSynodicMonth( Lunation ) = ( ^{2691067481897} / _91128068928 ) – ( ^Lunation / _3164169060 )

Using absolute calculation engines that preserve all integers and proper fractions without rounding, such as Mathematica, these MSM expressions yield the same results. However using ordinary floating-point computation, typical of calculators and normal computer programs, the algebraically simplified expression is more accurate because it involves substantially fewer calculation steps. In addition, the simplified expression can return a valid result even if the Lunation number has a fractional component, and its coefficients are also informative:

Setting Lunation = 0 yields the MSM at the epoch of the Hebrew calendar = ^{2691067481897}/_91128068928 = 29+^48353482985/_91128068928 ≈ 29.5306102 days, or about ⁴/₃ second longer than the traditional molad interval. Therefore we define:

MSMatEpoch = 29+^48353482985/_91128068928

The denominator dividing into the Lunation number implies that the MSM is changing at the rate of –¹/_3164169060 days per month:

MSMslope = –¹/_3164169060

Multiplying by the number of seconds per day = 86400 and by 1000000 to convert the result to microseconds, the Mean Synodic Month is getting shorter by about 27+¹/₃ microseconds per month (they are actually mean solar microseconds, but due to rounding of this figure the difference is insignificant in the present era). As there are ¹⁰/₃ seconds per part, this corresponds to about (27+¹/₃) / (¹⁰/₃) = ⁴¹/₅ "microparts" per month (where each "micropart" is one millionth of a part or chelek). Since the slope is negative, the symbolically substituted function becomes:

ProgressiveMoladInterval( Lunation ) = MeanSynodicMonth( Lunation ) = MSMatEpoch + Lunation × MSMslope

For example, as of Rosh Hashanah 5766 on the traditional Hebrew calendar, which was Lunation 71304, the MSM was nearly 600 milliseconds (³/₅ second or ⁹/₅₀ of a part) shorter than the traditional molad interval.

It is a trivial matter to rearrange the MeanSynodicMonth function to answer the question, "At which Lunation will the Mean Synodic Month be shorter than so-and-so?":

MeanSynodicMonthToLunation( MSM ) = ceiling( ( MSM – MSMatEpoch ) / MSMslope )

The ceiling function returns the integer that is greater than or equal to its operand (any fractional Lunation number will be returned as the next higher whole number), so by that time the Mean Synodic Month will be less than or equal to the specified length. The Lunation result can then be used, in Rectify mode to find the rata die using the MoladMoment function, then if desired the corresponding rectified Hebrew calendar date using the FixedToHebrew function.

I was curious to know when the Mean Synodic Month will be less than ⁷⁶⁵⁴³²/₂₅₉₂₀ = ¹⁰⁶³¹/₃₆₀ = 29+¹⁹¹/₃₆₀ days, because that will be exactly one part shorter than the traditional molad interval (note the interesting denominator = 360, which suggests to me that the original arithmetic intention was to express the synodic month in 360ths of a day, but later it was found necessary to "kick it up a notch" for acceptable accuracy). The MSM will be less than 29+¹⁹¹/₃₆₀ days after Lunation ceiling(^24898741/₁₄₄) = 172908. Dividing by the average number of months per year (⁴³⁶⁶/₃₅₃) the corresponding rectified Hebrew year number will be about 13980, which will be about a millennium beyond the predicted "no-solar-drift" era of the rectified Hebrew calendar with progressive molad.

After the progressive molad interval decreases to less than 29+¹/₂ days, occasional calendar years will have lengths that are too short, unless Shevat or some other traditionally 30-day month is also allowed in such cases to have only 29 days. That will not be necessary until after Lunation ceiling(^13947242605/₁₄₄) = 96855852 or roughly beyond rectified Hebrew year 7830994. Although this is only a very crude estimate based on extreme extrapolation of the perigee eclipse study, one can confidently consider it too far in the distant future to be of any concern!

MoladMoment( Rectify, 0 ) yields the epoch of the progressive molad, which was 10 hours and 14 minutes before the traditional molad epoch:

ProgressiveMoladEPOCH = TraditionalMoladEpoch – ¹⁰/₂₄ – ¹⁴/₁₄₄₀

Molad Intervals Determine Hebrew Calendar Mean Year Length

The traditional Hebrew calendar has a mean year of ( 235 months × MoladInterval ) / 19 years = 365 days 5 hours 55 minutes and 25 seconds, which is 6 minutes and 25 seconds too long per year, relative to the present era mean northward equinoctial year length.

With the traditional fixed molad interval the rectified Hebrew calendar mean year would be constantly equal to:

( 4366 months × MoladInterval ) / 353 years = 365 + ^1109039/_4574880 days = 365 days 5 hours 49 minutes 5+²⁵/₁₀₅₉ seconds

which is only about 5 seconds longer than the present northward equinoctial mean year. Therefore, by itself the 353-year leap cycle of the rectified Hebrew calendar will essentially eliminate the present-day solar drift of the traditional Hebrew calendar, and it is projected that it will maintain excellent northward equinox alignment for more than 4 millennia.

With the progressive molad, having progressively shorter molad intervals, the rectified Hebrew calendar mean year is given by the number of months per cycle (4366) multiplied by the Mean Synodic Month (in days) then divided by the number of years per cycle (353):

Lunation = ElapsedMonths( Rectify, hYear, hMonth )

RectifiedMeanYear( Lunation ) = 4366 × MeanSynodicMonth( Lunation ) / 353

For example, at the start of Tishrei 5766 on the rectified Hebrew calendar, Lunation = 71303, the MeanSynodicMonth function returns 29.5305876666475 days, so the rectified Hebrew calendar mean year was 4366 × 29.5305876666475 / 353 = 365.24239242445 days, which was about 6 minutes and 27 ¹/₃ seconds shorter than the traditional Hebrew calendar mean year.

The steady rate of change (for any Lunation number), in seconds, in the rectified Hebrew calendar mean year per 353-year cycle is given by:

86400 × ( RectifiedMeanYear( Lunation + 4366 ) – RectifiedMeanYear( Lunation ) )

= ^{–9149738880}/_6205287101 ≈ ^–3/₂ seconds per 353-year cycle

Therefore, with the progressive molad the rectified Hebrew calendar mean year will get steadily shorter at the rate of –³/₂ seconds per 353-year leap cycle or about –4 ¹¹/₅₉ seconds per millennium, with a present-day length of 365 days 5 hours 48 minutes 58 seconds, which is about 2 seconds shorter than the current mean northward equinoctial year. Calculations predict that this molad rectification will not only essentially eliminate the drift of the Hebrew calendar with respect to the mean lunar conjunctions, it will also enable the rectified Hebrew calendar to maintain its excellent alignment relative to the northward equinox for more than 7 millennia! That will be 3 millennia beyond the era when perihelion will have advanced to the northward equinox (perihelion is presently almost 13 days after the south solstice). The rectified Hebrew calendar with progressive molad will maintain alignment relative to that equinox for substantially longer than any other fixed arithmetic calendar ever devised!

A table linked to charts depicting the long-term equinox alignments of the traditional Hebrew calendar, rectified Hebrew calendar with traditional molad, and rectified Hebrew calendar with progressive molad appears in the discussion of the ElapsedMonths function, given above.

The following chart shows the progressively shorter mean year of the Rectified Hebrew Calendar as a diagonal solid black line sloping downwards, in comparison with several other calendars (horizontal lines having various styles) and with the mean astronomical equinoctial and solstitial year lengths (the dark green curve is the target mean northward equinoctial year length), all expressed as minutes and seconds in excess of 365 days 5 hours (mean solar time). (Click here or on the chart to open a high-resolution PDF version 21 KB)

Why not choose a simple fixed arithmetic lunar cycle for use with the 353-year lunisolar cycle? Due to the tidal slowing of the Earth rotation rate, the ideal fixed lunar cycle going forward should have a slightly short mean month, compared to the contemporaneous astronomical mean synodic month, so that it will remain reasonably drift-free for several thousand years into the future. The 353-year lunisolar cycle has 4366 months, which has {2, 37, 59, 74, 118, 2183, 4366} as divisors, but none of these yield a suitable lunar cycle. What about a least common multiple (LCM) of 4366 months? I found a 703-month lunar cycle (43 yerms, 330 deficient months, 373 full months) that has a slightly short mean month of 29+³⁷³/₇₀₃ days = 29d 12h 44m 2+²⁷⁴/₇₀₃s (≈ 2.390s) = 29.530583214793741109... days, which will closely match the mean synodic month during Hebrew years 6624 to 7476 or Gregorian years 2863 to 3716 (accordingly for optimal performance it should be used with a future epoch near the middle of this range of years, say Hebrew year 7000 or 7050). The intentionally slightly short lunisolar mean year would be 4366 months × (29+³⁷³/₇₀₃ days) / 353 years = 365+¹⁶²⁵/₆₇₀₇ days = 365d 5h 48m 53+²³⁶⁹/₆₇₀₇s ≈ 365.242284181 days (the exact decimal value has 288 repeating decimal points), which is about 3 seconds shorter than the mean year of the light green horizontal line on the chart above (labelled as Symmetry Calendar 365+71/293 in the chart legend). It turns out that 118 repeats of this 703-month lunar cycle exactly equal 19 repeats of the 353-year lunisolar cycle (19×353=6707 years), making a total of 82954 months (the LCM of 703 and 4366) or exactly 2449680 days, but would require 7 repeats to make a whole number of weeks for a full repetition cycle: 7×19×353 = 46949 years! Its part would be of rather long duration = ^{(86400 seconds per day)} / _{(703 parts per day)} ≈ almost 123 seconds per part! Although 46949 years is less than 7% of the profoundly long 689472-year full repetition cycle of the traditional Hebrew calendar, and I do expect both the solar and lunar components to perform well with respect to long-term calendar drift until perhaps Hebrew year 10000, nevertheless I don’t find the 703-month fixed lunar cycle compelling (mainly because the 1803-year lunisolar cycle with the superb 100-saros lunar cycle works very well and contains a whole number of weeks), but worth documenting here (as of 2022 May 9). [Karl Palmen of the UK independently discovered the 353-year / 703-month cycle combination on or before 2009 Aug 12, and included it in several of his on-line lunisolar cycle spreadsheets at http://the-light.com/cal/kp_Lunisolar_xls.html]

The First Day of Tishrei (Rosh Hashanah) — the HebrewNewYear Function

The initial arithmetic requirement for Hebrew calendar calculations, given any Hebrew year number, is to find the rata die (fixed date) of Rosh Hashanah (start of Tishrei) in that year, subject to the traditional Rosh Hashanah postponement rules. The novel arithmetic presented here is unique in that its logic is concerned only with the day of the molad, not the moment within the day. Nevertheless, when applied to the traditional Hebrew calendar, this logic generates dates that exactly match conventional methods for the entire 689472-year cycle of the traditional Hebrew calendar. All Rosh Hashanah rata die fixed dates returned by this HebrewNewYear( Traditional, hYear ) function are identical to those generated by the CC3 Hebrew calendar arithmetic, and the Rosh Hashanah postponement frequencies and year length frequencies exactly match those given by Remy Landau at <http://hebrewcalendar.tripod.com/#24.3> and at <http://hebrewcalendar.tripod.com/#24.4>, respectively, provided that parts are calculated separately from days in the traditional molad calculation, as specified in the MoladMoment function above.

The novel logic presented here has the following advantages:

• direct, efficient, intuitively clear logic;
• implements Rosh Hashanah postponement rules that are exactly equivalent to the traditional rules;
• requires only the day of the molad (the moment of the molad is irrelevant to the processing logic);
• retains full compatibility with the traditionally fixed molad interval, yet is also compatible with the progressively shorter progressive molad interval (traditional postponement logic requires a fixed molad interval);
• also compatible with use of an actual astronomical molad moment if desired in the future (such as the actual lunar conjunction, or a moment of predicted first visibility of the new lunar crescent), provided that the lengths of the calendar months are fixed according to the traditional rules (see the HopToNextMonth function).

At this point you are probably wondering, "Three out of four of the traditional Rosh Hashanah postponement rules refer to the moment of the molad. How can the logic possibly be so simplified so that it is no longer concerned with the moment of the molad and yet still retain full equivalence to the traditional Rosh Hashanah postponement rules?"

The key to this novel logic is a shortcut originally proposed by German Mathematician Johann Carl Friedrich Gauss (Gauß), who pointed out that since Hebrew calendar days start at sunset, one can bypass the molad zakein ("old molad") postponement rule by simply adding ¹/₄ day to the molad moment. If the original molad moment was past noon, then adding that ¹/₄ day automatically advances the molad moment to beyond the next sunset, thereby postponing Rosh Hashanah to the next day. While developing the arithmetic to make the progressively shorter progressive molad interval work with the rectified Hebrew calendar, I discovered that the same shortcut can be applied to the 3rd (Tuesday) and 4th (Monday) Rosh Hashanah postponement rules, thereby eliminating any need to know more than the day of the molad.

I found it convenient to implement the Gauss shortcut by putting a "shell" around the MoladMoment function, defining a MoladDay function as follows:

MoladDay( Mode, Lunation ) = floor( MoladMoment( Mode, Lunation, QuarterDay ) )

where QuarterDay = +0.25 and is passed as the Offset to the MoladMoment function.

The calling syntax for the HebrewNewYear function is:

RoshHashanah = HebrewNewYear( Mode, hYear )

The HebrewNewYear function starts by using the ElapsedMonths function to find the Lunation number for Tishrei of the given year, depending on the specified Hebrew calendar Mode:

Lunation = ElapsedMonths( Mode, hYear, Tishrei )

where Tishrei = 7, as it is the 7th month of the Hebrew calendar.

Store the Lunation number in a local variable, because it will be needed again when processing the Tuesday or Monday Rosh Hashanah postponement rules.

Next use the MoladDay function to get the provisional fixed date of either the traditional or progressive molad, depending on the Hebrew calendar Mode, with the molad zakein postponement rule already handled:

ThisHebrewNewYear = MoladDay( Mode, Lunation )

For checking the rest of the Rosh Hashanah postponement rules we need the Hebrew weekday of the molad, determined as an integer from 1=Sunday to 7=Saturday simply by adding one to the remainder of dividing the provisional Rosh Hashanah fixed date by 7, as was explained above:

MoladWeekday = modulus( ThisHebrewNewYear, 7 ) + 1

If the provisional Rosh Hashanah date is on any of the disallowed weekdays (Sunday, Wednesday, Friday), even if it got there because of the Gauss +0.25 day shortcut, then we postpone Rosh Hashanah by one day. This is the most commonly invoked Rosh Hashanah postponement rule.

IF ( MoladWeekday = YomRishon ) OR ( MoladWeekday = YomRivii ) OR ( MoladWeekday = YomShishi ) THEN

ThisHebrewNewYear = ThisHebrewNewYear + 1 ' postpone from disallowed to allowed weekday

If ThisHebrewNewYear is on Tuesday AND this year is not a leap year (according to the leap cycle of the given Hebrew calendar Mode) AND if the next molad of Tishrei will be on or after noon on Saturday then it will be postponed to Sunday and then to Monday. In that case, if we don't postpone this Rosh Hashanah then this year will be 356 days, which is one day too long for the allowable intervening month lengths. This Rosh Hashanah must be postponed from Tuesday to Wednesday, but since Wednesday is disallowed it must be postponed to Thursday. Traditionally this rule was checked indirectly by comparing this year's molad of Tishrei moment to a fixed cutoff time of 9 hours 204 parts (+6 hours if the Gauss shortcut had been applied to the molad moment), because after adding 12 times the traditional molad interval to that cutoff time the next molad of Tishrei lands at noon on Saturday. When using the progressive molad, however, with its progressively shorter molad interval, even the very small annual change is non-negligible and a fixed cutoff time won't work. Rather than complicating the arithmetic by progressively shifting the cutoff time, it is simplest just to directly check the next molad of Tishrei. This strategy is valid for the traditional molad, progressive molad, or an astronomical molad. After applying the Gauss +¹/₄ day shortcut for that future molad via the MoladDay function, the resulting year length indicates whether postponing this year is necessary. There is no need to call the ElapsedMonths function when calculating that future molad of Tishrei, because the Lunation number for this year was previously stored in a local variable (above), and knowing that this year is not a leap year the required future Lunation number is simply 12 lunations after that saved value:

ELSE IF MoladWeekday = YomShlishi THEN ' (Tuesday, uncommonly invoked rule, about once in 30 years)

IF NOT isHebrewLeapYear( Mode, hYear ) THEN ' this rule applies only if this is a non-leap year (12 months)

IF MoladDay( Mode, Lunation + 12 ) – ThisHebrewNewYear = 355 ' days in longest possible non-leap year
THEN ThisHebrewNewYear = ThisHebrewNewYear + 2 ' postpone this year from Tuesday to Thursday

END IF

Finally, the Monday rule is the last, rarely invoked Rosh Hashanah postponement rule. If ThisHebrewNewYear is on Monday AND the previous year was a leap year (according to the leap cycle of the given Hebrew calendar Mode) AND if the prior molad of Tishrei was on or after noon on Tuesday then it was postponed to Wednesday, which was disallowed so it was postponed again to Thursday. Now if this Rosh Hashanah would not be postponed then the prior leap year would have been only 382 days, which is one day too short for the allowable intervening month lengths. Therefore Rosh Hashanah this year must be postponed from Monday to Tuesday. Traditionally this rule was checked indirectly by comparing this year's molad of Tishrei moment to a fixed cutoff time of 15 hours 589 parts (+6 hours if the Gauss shortcut had been applied to the molad moment), because after subtracting 13 times the traditional molad interval from that cutoff time the previous molad of Tishrei was at noon on Tuesday. When using the progressive molad, however, with its progressively shorter molad interval, even the very small annual change is non-negligible and a fixed cutoff time won't work. Rather than complicating the arithmetic by progressively shifting the cutoff time, it is simplest just to directly check the previous molad of Tishrei. This strategy is valid for the traditional molad, progressive molad, or an astronomical molad. After applying the Gauss +¹/₄ day shortcut for that future molad via the MoladDay function, the resulting year length indicates whether postponing this year is necessary. As above, there is no need to call the ElapsedMonths function when calculating the previous molad of Tishrei, because the Lunation number for this year was previously stored in a local variable (above), and knowing that last year was a leap year its Lunation number was simply 13 lunations before that saved value:

ELSE IF MoladWeekday = YomSheini THEN ' (Monday, rarely invoked rule, about once in 186 years)

IF isHebrewLeapYear( Mode, hYear – 1 ) THEN ' this rule applies only if previous year was leap (13 months)

IF ThisHebrewNewYear – MoladDay( Mode, Lunation – 13) = 383 ' days in shortest possible leap year
THEN ThisHebrewNewYear = ThisHebrewNewYear + 1 ' postpone this year from Monday to Tuesday

END IF

END IF

It so happened that this rarely invoked rule did apply to Rosh Hashanah 5766 on the traditional Hebrew calendar. The molad of Tishrei 5766 was on Monday at 16h 48m 12p after sunset, which was before noon (18h). Ordinarily, therefore, Rosh Hashanah would have been observed on that Monday. The prior year, however, was a leap year, and the molad of Tishrei 5765 was on Tuesday after noon, so Rosh Hashanah 5765 was postponed to Thursday. Therefore if Rosh Hashanah 5766 had not been postponed then the leap year 5765 would have been only 382 days long, which is too short for the possible intervening month lengths. For this example, Lunation = ElapsedMonths( Traditional, 5766, Tishrei ) = 71304, and MoladDay( Traditional, 71304 ) = 732222. The above logic requires that we get MoladDay( Traditional, 71304 – 13 ) = 731839. The difference, 732222 – 731839 = 383, is the shortest allowable length of a leap year, thus triggering the one day postponement as above.

The HebrewNewYear function finishes by simply returning the finalized Rosh Hashanah fixed date, which includes any postponements that were applied:

RETURN ThisHebrewNewYear

On the Rectified Hebrew Calendar: Advanced Topics web page you can view an alternative HebrewNewYear function which substitutes a simple MOD expression for the multi-part IF statement when checking for disallowed Rosh Hashanah weekdays, and which also avoids calculating the length of the year for the Tuesday and Monday postponement rules. I personally prefer the version given above, but others may prefer the alternate. Either way, the Rosh Hashanah dates are identical.

As shown in the tables below, on the rectified Hebrew calendar, the Rosh Hashanah postponement frequencies and weekday distributions are essentially the same as the traditional Hebrew calendar. As usual, Rosh Hashanah starts on the day of the molad in less than 40% of years, is postponed by one day in more than 46% of years, and is postponed by two days in about 14% of years. Tuesday is the least common starting weekday for Rosh Hashanah (a bit more than 11% of years), and Thursday is the most common (almost ¹/₃ of years, which makes for a very long weekend with the High Holy Days on Thursday and Friday, then the Sabbath on Saturday for Rosh Hashanah plus, outside Israel, the same for the first two and last two days of Sukkot).

Rectified Rosh Hashanah Shift Frequency and Weekdays
(number of years per 1000 years, disallowed weekdays are Sunday, Wednesday, Friday)

Year Range	Postpone 0	Postpone 1	Postpone 2	Monday	Tuesday	Thursday	Saturday
3001-4000	389	471	140	284	111	319	286
4001-5000	394	465	141	279	117	314	290
5001-6000	386	470	144	280	115	319	286
6001-7000	388	473	139	281	115	322	282
7001-8000	395	466	139	285	112	321	282
8001-9000	393	467	140	280	116	316	288
9001-10000	378	477	145	281	113	321	285

Traditional Rosh Hashanah Postponements and Weekdays
(number of years per 1000 years, disallowed weekdays are Sunday, Wednesday, Friday)

Year Range	Postpone 0	Postpone 1	Postpone 2	Monday	Tuesday	Thursday	Saturday
4001-5000	394	469	137	277	116	318	289
5001-6000	388	469	143	282	114	319	285
6001-7000	390	468	142	280	117	316	287
7001-8000	390	470	140	280	114	323	283
8001-9000	387	471	142	280	115	318	287
9001-10000	390	469	141	278	116	318	288

Looking at the reasons for the postponements compared to the traditional Hebrew calendar, the Rosh Hashanah postponements of the rectified Hebrew calendar are almost the same, based on my analysis of 689472 Hebrew years. Note, however, that the 689472-year cycle of the traditional Hebrew calendar does not apply to the rectified Hebrew calendar, which, due to the progressively shorter progressive molad interval, never repeats!

On the rectified Hebrew calendar, the pure molad zakein (moment of molad after noon, postponed to the next weekday) has the expected frequency of 1 per 7 years (14.29%). Molad zakein postponed to a disallowed weekday then postponed again has the expected frequency of 3 per 28 years (10.71%). Postponement purely on the basis of the molad moment landing on a disallowed weekday has the expected frequency of 9 per 28 years (32.14%). Thus the total of all disallowed weekday postponements equals the expected frequency of ³/₂₈+⁹/₂₈ = ³/₇ = 42.86%. The frequency of the Tuesday postponements in non-leap years is slightly reduced, and the frequency of Monday postponements after leap years is slightly increased, because the progressive molad interval gets progressively shorter:

Hebrew Calendar:	Rectified		Traditional
Postponement Type	% of Years	Years/Frequency	% of Years	Years/Frequency
Tuesday of non-leap year	3.20%	31.3	3.31%	30.2
Monday after leap year	0.62%	160	0.54%	185.7

This Rosh Hashanah status chart includes the rectified tables above and also graphically depicts the elapsed time of Rosh Hashanah with respect to the actual astronomical lunar conjunctions (101 KB), showing slight changes over the millennia. Contrast that with the same type of chart and tables for the traditional Hebrew calendar (93 KB), which shows a wider range of variability relative to the lunar conjunctions and progressive changes over the coming millennia (due to the molad moments drifting later and later).

How Many Days are in Hebrew Calendar Years?

Now that we can compute the fixed date of Rosh Hashanah for any desired Hebrew year, it is easy to calculate the length of any given year by simply subtracting it from the fixed date for the next year's Rosh Hashanah. When necessary, this calculation is used by the HopToNextMonth function in determining the lengths of Cheshvan and Kislev, and it is useful for comparing the rectified Hebrew calendar year length frequencies to the traditional Hebrew calendar:

DaysInHebrewYear( Mode, hYear ) = HebrewNewYear( Mode, hYear + 1 ) – HebrewNewYear( Mode, hYear )

Although one could distinguish between non-leap (12 months) or leap (13 months) years by checking if the year length is greater than any number that is intermediate between the lengths of non-leap years and the lengths of leap years, such as 365 days, the isHebrewLeapYear function returns the year leap status much more efficiently.

For both the traditional and rectified Hebrew calendars, the only possible year lengths are 353, 354, 355, 383, 384 or 385 days. Of these, only 385 is divisible by 7 = exactly 55 weeks, so in the case of a perfect (full) leap year the following year will always start on the same weekday.

The year length frequencies and proportion of years that are "Deficient", "Normal" or "Full" are essentially the same as the traditional Hebrew calendar:

Year Length Frequences of the Rectified Hebrew Calendar
(progressive molad, number of years per 1000 years, measured from Rosh Hashanah)

Year Range	Non-Leap Years			Leap Years
	353 days	354 days	355 days	383 days	384 days	385 days
	Deficient	Normal	Full	Deficient	Normal	Full
3001-4000	100	244	288	155	52	161
4001-5000	102	241	288	154	54	161
5001-6000	102	244	286	153	52	163
6001-7000	100	242	290	154	54	160
7001-8000	98	243	291	158	52	158
8001-9000	99	244	288	156	52	161
9001-10000	99	243	290	156	53	159

Year Length Frequences of the Traditional Hebrew Calendar
(traditional molad, number of years per 1000 years, measured from Rosh Hashanah)

Year Range	Non-Leap Years			Leap Years
	353 days	354 days	355 days	383 days	384 days	385 days
	Deficient	Normal	Full	Deficient	Normal	Full
4001-5000	100	243	288	156	52	161
5001-6000	100	245	287	155	51	162
6001-7000	102	241	288	153	55	161
7001-8000	99	243	290	156	52	160
8001-9000	100	244	288	155	52	161
9001-10000	101	244	286	154	51	164

The First Day of Nisan — the NisanFirstDay Function

I have chosen to handle the rest of the calendar arithmetic relative to the start of Nisan rather than Tishrei, because Nisan is traditionally considered to be the first month of the calendar (even though the civil year number is incremented at the start of Tishrei). This allows the arithmetic to "hop" from month-to-month in numeric sequence, and the "hopping" can ignore the leap status of the year.

The starting date of Nisan is simply a fixed number of days before the next Rosh Hashanah. That is, we find the start of Tishrei for next year, then back up by the fixed number of days from the start of Nisan to the start of Tishrei. The interval is fixed in length because all of the months from Nisan through Elul have fixed lengths (Nisan=30, Iyar=29, Sivan=30, Tammuz=29, Av=30, Elul=29 ), which add up to 177 days.

NisanFirstDay( Mode, hYear ) = HebrewNewYear( Mode, hYear + 1 ) – 177

That's it! The result of the NisanFirstDay function is the rata die or CC3 fixed date of the first day of Nisan in the specified rectified Hebrew calendar year.

Why bother having a separate function since it is a trivial matter to subtract the 177-day offset whenever necessary? It keeps the program code easier to read in the functions that call NisanFirstDay, but the main reason is to provide for the future incorporation of the NisanFirstDay logic of the astronomical Hebrew calendar, which involves substantially more Nisan-specific processing in relation to the actual astronomical northward equinox and actual nearest astronomical lunar conjunction moments.

The NisanFirstDay function determines the equinox-relative alignment of the first day of Nisan, depending in the case of the rectified Hebrew calendar on the Δ value that is used in the ElapsedMonths function. Using the recommended Δ = 138 on average the spring equinox will occur within less than a day before the start of Nisan, with about half of the equinoxes occuring during the "renewal of the Moon" in the first half of Nisan and the remainder occuring during the last half of the prior month. The latest equinoxes will land on the 15th of Nisan (first day of Passover). Charts depicting these equinox alignments, in comparison with the traditional Hebrew calendar, were given above in the ElapsedMonths function.

The HopToNextMonth Function

After finding the fixed date of the start of Nisan, we need to be able to find the beginning of all subsequent months until the next Nisan. This is fairly simple because all month lengths are traditionally fixed except Cheshvan and Kislev, whose lengths depend on the length of the year, which depends on the Rosh Hashanah postponements. The HopToNextMonth function returns the fixed date of the first day of the next month, which actually begins at the moment of the prior sunset. The calling syntax is:

StartOfNextMonth = HopToNextMonth( Mode, MonthStart, hYear, hMonth )

where MonthStart is the rata die of the start of the month that we are hopping from (this would initially be the value returned from the NisanFirstDay function), and hMonth is the Hebrew month number of the month that corresponds to MonthStart ( Nisan = 1 ... Tishrei = 7 ... Adar or Adar Rishon = 12, Adar Sheini = 13).

All months have at least 29 days, so this HopToNextMonth starts by presetting the return value to MonthStart + 29:

NextMonthStart = MonthStart + 29

All we have left to do is determine if the next month is a 30-day month, in which case we simply add another day to NextMonthStart. Using a SELECT CASE statement, we find all of the 29-day months and get out. If program execution makes it to the end of the SELECT CASE statement then the next month has 30 days.

SELECT CASE hMonth

CASE Iyar, Tammuz, Elul, Tevet, AdarSheini

RETURN NextMonthStart

CASE Adar ' month 12 can be Adar =29 days or, in a leap year, Adar Rishon = 30 days

IF NOT isHebrewLeapYear( Mode, hYear ) Then RETURN NextMonthStart

In "Deficient" years (353 or 383 days), Cheshvan and Kislev both have 29 days. In "Regular" years (354 or 384 days), Cheshvan has 29 and Kislev 30 days. In "Full" years (355 or 385 days), Cheshvan and Kislev both have 30 days. We only need to find the cases where the requested month is 29 days, so that we can get out at that point, otherwise we let execution reach the end of the SELECT CASE statement. Cheshvan has 29 days if the year is not Full, and Kislev has 29 days only if the year is Deficient.

CASE Cheshvan ' get out unless this is a Full year

YearLength = DaysInHebrewYear( Mode, hYear )

IF YearLength <> 355 AND YearLength <> 385 THEN RETURN NextMonthStart

CASE Kislev ' get out if this is a Deficient year

YearLength = DaysInHebrewYear( Mode, hYear )

IF YearLength = 353 OR YearLength = 383 THEN RETURN NextMonthStart

END SELECT

If execution reaches this point (past the END SELECT statement), then we have a 30-day month, so return NextMonthStart + 1. The months that always have 30 days are Nisan, Sivan, Av, Tishrei, and Shevat.

RETURN NextMonthStart + 1

Click here to see a report showing that on the rectified Hebrew calendar the patterns and frequencies of Deficient (29-day) and Full (30-day) months are essentially the same as the traditional Hebrew calendar (62 KB).

The FixedToHebrew Function

Given any CC3 fixed date, the FixedToHebrew function converts the rata die to a mode-specific Hebrew calendar date. It can be used as the last stage of converting any other calendar date, for example from the Calendrica Applet, to its corresponding mode-specific Hebrew Date.

The calling syntax depends on the capabilities of the programming environment, because this function receives two parameters ( Mode, FixedDate ) and returns multiple properties representing the corresponding mode-specific Hebrew date ( year, month, day, weekday, optionally other information required for the application).

As specified in the Torah and Talmud, and as recommended for computer implementations by Dershowitz & Reingold in CC3, Hebrew calendar months are numbered starting from Nisan = 1 to Tishrei = 7 to Adar = 12 and in leap years Adar Rishon = 12 and Adar Sheini = 13.

This function starts with an estimate of the Hebrew year, calculated by dividing the number of days elapsed since the calendar epoch by a mode-specific mean year length (plus one because the first year was year one not year zero).

IF Mode = Traditional THEN

' for Traditional mode use the fixed mean year length of the traditional Hebrew calendar

MeanYear = 235 × MoladInterval / 19

ELSE ' Mode = Rectify

' for Rectify mode use the present-day mean northward equinoctial year length

MeanYear = ⁵²⁵⁹⁴⁹/₁₄₄₀ ' = 365 days 5 hours 49 minutes 0 seconds = 365 + ⁵/₂₄ + ⁴⁹/₁₄₄₀ days ≈ 365.242361 days

END IF

hYear = floor( ( FixedDate – HebrewEPOCH ) / MeanYear ) + 1

At this point, due to the variations of the leap cycle, hYear may be the correct year number or it may be the year before or after the correct year, to be determined by a date search. The possible cases to be handled by the date search strategy are:

• In the simplest case, if the FixedDate is on or after the start of Nisan but before mid Elul then the estimated year will be correct, in which case the search will directly "hop" forward from the Nisan of that year until it finds the date.
• If the FixedDate is more than halfway through Elul then the year could be correct, in which case the search will directly hop forward from the Nisan of that year until it finds the date in Elul.
• Alternatively with a FixedDate more than halfway through Elul the estimated year could land in the next year, in which case the search will start from the next Nisan but that will immediately found to be beyond the target date, so the search will back up to the Nisan of the previous year and hop through the months until it finds the target date in Elul.
• With a FixedDate in the first half of Tishrei the estimated year might be the prior year, in which case the search will start directly from the Nisan before the FixedDate, hop through months from there, increment the year at the start of Tishrei, then find the correct date.
• With a FixedDate in the first half of Tishrei the estimated year could be correct, but when the search starts from the Nisan of that year it will find that it has gone past the target date. It will then back up to the Nisan of the previous year, hop through months from there, re-increment the year at the start of Tishrei, then find the correct date.
• If the FixedDate is after mid Tishrei but before Nisan then the year will be correct, but when the search starts from the Nisan of that year it will find that it has gone past the target date. The search will then back up to the Nisan of the previous year, hop through months from there, re-increment the year at the start of Tishrei, then find the correct date.

Using the estimated hYear, get the rata die of the first day of Nisan of that year:

MonthStart = NisanFirstDay( Mode, hYear )

Next, compare that MonthStart with the given FixedDate, and if already past that date then jump back to the previous Nisan. The easiest, albeit least likely, case is where the given fixed date just happens to be at the beginning of Nisan, so the search starts by defaulting hMonth to Nisan and after that checking the FixedDate:

hMonth = Nisan ' start the search from Nisan

IF MonthStart <> FixedDate THEN ' if the fixed date is the first day of Nisan then that was easy, no more searching necessary

IF FixedDate < MonthStart THEN ' otherwise if the fixed date is earlier then jump back to the previous Nisan

hYear = hYear – 1
MonthStart = NisanFirstDay( Mode, hYear )

END IF

END IF

If the fixed date is after the beginning of Nisan then the correct Nisan has been found and the search can go forward from there. Otherwise the FixedDate was prior to Nisan, so the search must go back to the previous Hebrew year and use the NisanFirstDay function to get the fixed date of its first day of Nisan, which is guaranteed to be less than one Hebrew year prior to the unknown target date. After the start of the correct Nisan is known the search is ready to "hop" forward from month-to-month until it finds the correct month.

If the initial start of Nisan was before FixedDate then the target date must be within 6-7 months of that Nisan, so the leap status of that year or the next year is irrelevant. If the FixedDate was before the initial Nisan then the search is about to start from the previous Nisan, and FixedDate can't be equal to or later than the original Nisan. In this case, if the search hops forward from month-to-month and find itself in the 13th month then the decremented hYear is a leap year, but there is no need to check for that condition.

The search will now hop forward from month-to-month using the HopToNextMonth function to handle each hop according to the traditionally fixed lengths of the Hebrew calendar months:

DO

NextMonthStart = HopToNextMonth( Mode, MonthStart, hYear, hMonth )

IF NextMonthStart > FixedDate THEN EXIT DO ' would be too far if we hop again, so get out of loop

hMonth = hMonth + 1 ' otherwise increment to next month

IF hMonth = Tishrei THEN hYear = hYear + 1 ' and if we have reached Tishrei then also increment to next year

MonthStart = NextMonthStart ' get ready for next time around the loop

IF MonthStart = FixedDate THEN EXIT DO ' required day is on MonthStart, so get out of loop

LOOP

Starting from the beginning of the preceding DO-LOOP block, the search loop lets HopToNextMonth compute the fixed date of the first day of the next month, taking into account when necessary the variable lengths of Cheshvan, Kislev and the 12th month of the year (Adar = 29 days, leap month of Adar Rishon = 30 days). After the program exits from the DO-LOOP block, the variable MonthStart has the fixed date of the first day of the correct Hebrew month, and hMonth has the month number of that month, counting from Nisan=1 as explained above. The last thing to do is calculate the day number within that month, which is simply given by:

hDay = FixedDate – MonthStart + 1

The algorithm has now converted the given fixed date to a separated mode-specific Hebrew Date, with the year in hYear, the month in hMonth, and the day of the month in hDay. Optionally it can also determine the weekday of the fixed date in the same way that the molad of Tishrei weekday number was determined in the HebrewNewYear function given above, using the FixedDate value:

weekday = modulus( FixedDate, 7 ) + 1

where Yom Rishon (Sunday) = 1 through Shabbat (Saturday) = 7.

Once the mode-specific Hebrew date is determined, the programmer may elect to return additional information about that date, such as the year number within the leap cycle, the leap status of the year, day number within the year, any special ritual significance to the date, any of a variety of zmanim that are locale-specific, etc., as required for the application. The optimal method to return multiple properties depends on the capabilities of the programming environment.

The HebrewToFixed Function

The HebrewToFixed function converts any given mode-specific Hebrew Date to the corresponding CC3 fixed date. The calling syntax is:

FixedDate = HebrewToFixed( Mode, hYear, hMonth, hDay )

HebrewToFixed can be used as the first stage of converting any mode-specific Hebrew Date to its corresponding date on any other calendar, for example using the Calendrica Applet to do the rest of the job. This function is also useful in calculating how many days apart two mode-specific Hebrew Dates are, or calculating what the mode-specific Hebrew Date was or will be a certain number of days into the past or future. For example, to calculate the difference between two mode-specific Hebrew Dates:

DateDifference = HebrewToFixed( Mode, hYear2, hMonth2, hDay2 ) – HebrewToFixed( Mode, hYear1, hMonth1, hDay1 )

Or, if one wanted to know what will be the date a certain Offset number of days before (negative Offset) or after (positive Offset) a given mode-specific Hebrew Date:

OffsetDate = HebrewToFixed( Mode, hYear, hMonth, hDay ) + Offset

Then use FixedToHebrew( OffsetDate ) function to determine the desired mode-specific Hebrew Date.

For dates in Nisan through Elul we will hop from month-to-month starting from Nisan of the given Hebrew year, but for dates in Tishrei through Adar Sheini we search from Tishrei:

IF hMonth >= Tishrei THEN

HopFrom = Cheshvan ' start hopping from the 8th month

MonthStart = HebrewNewYear( Mode, hYear )

ELSE

HopFrom = Iyar ' start hopping from the 2nd month

MonthStart = NisanFirstDay( Mode, hYear )

END IF

The variable MonthStart now has the CC3 fixed date of the first day of the month that we are going to start searching from. Next, we will "hop" from month-to-month until we reach the required hMonth. If the given hMonth is Nisan or Tishrei then we don't need the FOR-NEXT loop to do anything, because we already have the rata die that starts the given month:

FOR Hop = HopFrom TO hMonth ' if hMonth is the month before HopFrom then this FOR-NEXT loop will do nothing

MonthStart = HopToNextMonth( Mode, MonthStart, hYear, Hop – 1 )

NEXT Hop

After execution of the above FOR-NEXT block we have in the variable MonthStart the fixed date of the first day of the given month hMonth. All that is left to do is to add in the day number within the month, and, because MonthStart is already on the first day, subtract one day:

RETURN MonthStart + hDay – 1

As written, if the user specifies an hDay=30 for a month that actually has only 29 days, then the returned fixed date will be that which corresponds to the first day of the next month, without any explicit processing needed to handle or check for that condition.

The HebrewMonthLength Function

The rectified Hebrew calendar establishes month lengths in the same manner as the traditional Hebrew calendar. Both calendars always agree on the lengths of all months except for the 8th (Cheshvan), 9th (Kislev), and 12th month (Adar or Adar Rishon). The lengths of Cheshvan and Kislev depend only the length of the year, as explained in the HopToNextMonth function above, which occasionally differs between the calendars because of year leap status differences or, less commonly, due to the progressive vs. traditional molad. The length of the 12th month depends only on year leap status, which, as just stated, occasionally differs between the calendars, also as explained in the HopToNextMonth function above.

When generating calendars for display or printout, it is necessary to know how far to enumerate the dates for each month. The calling syntax for the HebrewMonthLength function is:

MonthLength = HebrewMonthLength( Mode, hYear, hMonth )

The HebrewMonthLength function calculates the length of the specified month by subtracting the fixed date of the first day of the given month from the fixed date of the first day of the next month:

StartOfMonth = HebrewToFixed( Mode, hYear, hMonth, 1 )

RETURN HopToNextMonth( Mode, StartOfMonth, hYear, hMonth ) – StartOfMonth

Note that as written, if you ask for the 13th month of a non-leap year, HebrewToFixed will return the start of Nisan, so if you ask for the length of the 13th month of a non-leap year, HebrewMonthLength will return the length of Nisan.

Converting Hebrew Dates

To convert any traditional Hebrew calendar date to a rectified Hebrew calendar date, use HebrewToFixed in Traditional mode to convert the traditional Hebrew calendar date to a rata die fixed date, then use FixedToHebrew in Rectify mode to convert the fixed date to a rectified Hebrew calendar date.

Conversely, to convert any rectified Hebrew calendar date to a traditional Hebrew calendar date, use HebrewToFixed in Rectify mode to convert the rectified Hebrew calendar date to a rata die fixed date, then use FixedToHebrew in Traditional mode to convert the fixed date to a traditional Hebrew calendar date.

To convert any other calendar to a Hebrew calendar date, first convert the other calendar date to a rata die fixed date (if you don't have your own way to do this, simply use the on-line Calendrica applet of Dershowitz & Reingold at <http://emr.cs.iit.edu/home/reingold/calendar-book/Calendrica.html>), then use FixedToHebrew in your choice of Traditional or Rectify mode to convert that fixed date to the traditional or rectified Hebrew calendar date, respectively.

To convert any traditional Hebrew calendar date to another non-Hebrew calendar, use HebrewToFixed in Traditional mode to convert the traditional Hebrew calendar date to a rata die fixed date, then use your own software or the Calendrica applet to convert the fixed date to the desired non-Hebrew calendar date.

To convert any rectified Hebrew calendar date to another non-Hebrew calendar, use HebrewToFixed in Rectify mode to convert the rectified Hebrew calendar date to a rata die fixed date, then use your own software or the Calendrica applet to convert the fixed date to the desired non-Hebrew calendar date.

Checking if a Date is Valid

To check if any Hebrew calendar date exists, which may be especially useful to know for the 30th day of any month (although the HebrewMonthLength function above will indicate that) or for all dates in the month of Adar Sheini, it is simple to use the procedure recommended by Dershowitz & Reingold in CC3: convert the calendar date to a fixed date, then convert the fixed date back to the same calendar — if the returned date is the same as the original date, then the original date exists. Here is an example of such a HebrewToFixed — FixedToHebrew procedure:

FixedDate = HebrewToFixed( Mode, hYear1, hMonth1, hDay1 )

Then use FixedToHebrew( Mode, FixedDate ) to convert back to hYear2, hMonth2, and hDay2, and finally verify that we got back what we started with:

DateExists = ( hYear1 = hYear2 ) AND ( hMonth1 = hMonth2 ) AND ( hDay1 = hDay2 )

The boolean variable DateExists is set to TRUE if the original date is a valid rectified or traditional Hebrew calendar date, depending on the specified Mode, or FALSE otherwise. Of course if one is wondering about the days of Adar Sheini (Adar 2), simply checking if it is a leap year will indicate whether those dates exist. The HebrewToFixed — FixedToHebrew procedure given above, however, is generically convenient for checking any date.

Advanced Topics

Additional topics covering advanced aspects of the rectified Hebrew calendar, including arithmetic that is not essential for the calendar itself, and noteworthy variants of the calendar are offered separately on the Rectified Hebrew Calendar: Advanced Topics web page.

Comments and Suggestions Received

Comments and suggestions received to date, and their status with regard to changes of this document are separately tabulated on this page.