An Astronomical Hebrew Calendar (conjunction+24h)

Menu of Topics:

Design Goals
Overview
Sources for Astronomical Algorithms
Fixed Dates — the Rata Die
The Locale in Jerusalem
Predicting First Visibility of the New Lunar Crescent
The First Day of Nisan — the NisanFirstDay Function
Is it an Astronomical Hebrew Leap Year?
The HopToNextMonth Function
The ShiftRoshHaShanah Function
The FixedToAstroHebrew Function
The AstroHebrewToFixed Function
Checking if a Date is Valid
Comparing Hebrew Calendars
Lunar Cycle Alignment
Solar Cycle Alignment
Variants of this Astronomical Hebrew Calendar

Design Goals

The motives and design goals for developing this experimental astronomical Hebrew calendar are:

To show that it is possible to devise a ritually acceptable Hebrew calendar that employs astronomical algorithms and remains simultaneously drift-free with respect to both the solar and the lunar cycles.
To replace the molad of the fixed arithmetic traditional Hebrew calendar (which does not relate direct directly to any astronomical cycle, as explained on my web page The Molad of the Hebrew Calendar) with the actual moment of the lunar conjunction, as determined by modern astronomical algorithms, starting each month at the Jerusalem sunset that is nearest to one day after that moment.
As an example of "best possible performance" of a drift-free Hebrew calendar, this astronomical Hebrew calendar served as a yardstick for developing the simpler arithmetic approximations that were implemented in the Rectified Hebrew calendar.
To use as a reference for comparison with classical rabbinic astronomical and calendrical algorithms.
To implement this calendar as a computer program and place it in the public domain (by means of this web page) as a demonstration of the ease with which it can be put into practise.
To generate data, statistics, and graphical analyses to prove that the calendar achieves its design goals and that its rules and logic are fundamentally valid, especially by demonstrating that illegal month and year lengths never occur.
Unlike the classical observational calendar, the dates generated by this calendar are predictable and reproducible for the past and future, within the limitations of its astronomical algorithms. 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.

Overview

This astronomical Hebrew calendar ("sunset on day after conjunction" variant) is a lunisolar calendar modeled after the classical observational Hebrew calendar, where the leap status of the year is evaluated directly in comparison with the moment of the northward equinox, as predicted by modern astronomical algorithms used to compute the moment when the Solar Longitude is 0°. The leap month is inserted as necessary to keep the end of the first day of Passover (15th day of Nisan) within the first 30 days after the equinox. Restated, over the long term, the average northward equinox moment is close to the beginning of the month of Nisan.

The month of Nisan starts at the sunset that is closest to 24 hours after the moment of the actual lunar conjunction (New Moon) [in other words, the first sunset that is at least ¹/₂ day after conjunction] of the last lunar month that will allow the equinox moment to be before the sunset at the beginning of the 16th day of Nisan. The moment of sunset and its relation to the actual lunar conjunction are determined using astronomical algorithms computed for the locale of Jerusalem, taking elevation into account.

A given civil year is a leap year (13 months) if the start of Nisan of the given year is more than 12 months after the start of the previous Nisan. This rule yields a leap year every 2 or 3 years, with leap years as uniformly spread as possible, while preventing the moment of sunset at the beginning of the second day of Passover (16th day of Nisan) from drifting earlier than the equinox moment or beyond 30 days after the equinox.

After Nisan, each month starts at the sunset at the end of the 29th day of the previous month if that sunset is more than ¹/₂ day after its nearest actual lunar conjunction, otherwise it starts at the sunset at the end of the 30th day. Thus any month can be 29 or 30 days, but no other month length is legal (or possible).

If, according to the above rules, Rosh HaShanah initially lands on Sunday, Wednesday, or Friday, which are ritually inconvenient weekdays, then it is shifted by one day to an adjacent allowable weekday as follows: If Elul has 30 days then Rosh HaShanah is advanced one day earlier, leaving Elul with 29 days, otherwise Rosh HaShanah is postponed one day later, giving a 30th day to Elul.

Although the civil year number is incremented at Rosh HaShanah, its date is fixed in the classical manner relative to the first day of Nisan of the prior civil year number, which itself is fixed relative to the northward equinox. I will present at the end a chart showing the long-term alignment of the astronomical Rosh HaShanah relative to the southward equinox, but please note that it is impossible to design a calendar that simultaneously stays aligned with both equinoxes, because their respective equinoctial years lengths are different and are changing at different rates. Currently the southward equinoctial year length is changing much more rapidly than and is shorter than the northward equinoctial year — for details please see my web page entiteld "The Lengths of the Seasons".

Sources for the Astronomical Algorithms

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. The user is required to implement the following CC3 functions (and the functions that they depend on), or provide equivalents:

I also included selected astronomical 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.

Fixed Dates — the rata die

The computer functions for implementing this astronomical 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 traditional Hebrew calendar has a fixed date epoch of –1373427, which was Tishrei 1 of Hebrew year 1. It so happened that the epoch of the astronomical Hebrew calendar, based on the astronomical rules outlined in the Overview above, was the same. 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.

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, an astronomical 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 astronomical Hebrew calendar date.

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 Double Precision floating point variables, 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.

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 an epoch near the present era. 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 January 1st of the year 1 AD, or January 1st of the year 2001 AD (the beginning of the third Gregorian millennium), or it can enumerate days relative to any user-selected arbitrary date in the past or future.

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.

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.

Predicting First Visibility of the New Lunar Crescent

The astronomical Hebrew calendar employs modern astronomical algorithms to compute the moments of the actual lunar conjunction, actual northward equinox, and actual sunset in Jerusalem. The calendar arithmetic does not involve any attempt to compute the moment of first visibility of the new lunar crescent. However such computations are of some use in comparative evaluations of this calendar with the traditional Hebrew calendar.

Lunar crescent visibility varies with weather conditions, clouds, atmospheric dust and clarity (especially in the westerly direction), temperature, humidity, nearby and westerly light pollution, and local elevation with unobstructed view of the horizon. Astronomically it depends on the apparent lunar size and brightness, elongation from Sun, and altitude above the horizon at sunset. Human factors include observer maturity, truthfulness, sanity, visual acuity and stereoscopic perception, iris pigmentation and pupil diameter, experience and preparation, and the use of optical aids such as telescopes or binoculars. It also helps a lot to know exactly when and where to look, and then to actually look at the correct position in the sky!

The probability of false sighting for a typical observer has been estimated at 15%, hence observational calendars that depend on a few positive sightings from a large number of observers will almost invariably start early by mistake. False sightings can, however, be refuted if the Moon was actually below the horizon or ahead of the actual lunar conjunction at the moment when it is claimed the new lunar crescent was seen. If the moment of the actual lunar conjunction is known to good accuracy (better than ±1 minute is easy to calculate), then testimony claiming a sighting less than 24 hours later is highly doubtful (see the end of this section).

For the prediction of the visibility of the new lunar crescent, for evaluation of the astronomical Hebrew calendar, I use the following mathematical criteria as recommended by Dershowitz & Reingold in CC3, as implemented in their visible-crescent function:

for the locale of Jerusalem, Israel, compute the moment when the mid-point of Sun is 4.5° below the western horizon, so that the western sky is dark enough for possible observation of the new lunar crescent;
at that moment, if Moon has not yet passed its solar conjunction, then the crescent can't possibly be seen;
otherwise, for that moment, compute the arc-of-light from the geocentric mid-point of Sun to the geocentric mid-point of Moon (the "elongation" of Moon from Sun as if viewed from the center of Earth) — if the arc-of-light is less than 10.6° then the crescent will probably not be visible;
otherwise, for the same moment, compute the lunar altitude (above the western horizon) — if Moon will be less than or equal to 4.1° above the horizon, then the crescent will probably not be visible, even if the arc-of-light is sufficient.

The above criteria ignore the apparent lunar diameter (Moon can appear up to 25% larger at closest perigee than at furthest apogee, for example see the photograph that NASA has posted at <http://antwrp.gsfc.nasa.gov/apod/ap071025.html>) and the CC3 algorithms ignore atmospheric refraction and lunar parallax when calculating the lunar altitude. When Moon is near the horizon, atmospheric refraction makes the apparent lunar position as seen from the surface of Earth (topocentric position) about ¹/₂ degree higher than its position calculated as calculated for the center of Earth (geocentric position), and lunar parallax makes Moon appear about one degree lower, so the net effect of atmospheric refraction and lunar parallax will make Moon appear about ¹/₂ degree lower than the calculation. This partially accounts for "optimistic" first visible lunar crescent predictions.

Published crescent visibility reports, such a those of the Israeli New Moon Society available at <http://sites.google.com/site/moonsoc/sightings>, rarely document reliable sightings any earlier than 24 hours after conjunction, even with optical aids. Therefore the above criteria are probably optimistic even when applied to ideal observing conditions.

The First Day of Nisan — the NisanFirstDay Function

The first requirement, given any Hebrew year number, is to find the moment of the northward equinox in that year. The CC3 solar-longitude-after function is convenient for searching for the actual moment of the equinox, but must start its search from an estimated moment that is known to be not more than one year prior to the target equinox, such as the prior Gregorian New Year Day, at which the Gregorian year is 3760 less than the Hebrew year number:

Start = fixed-from-Gregorian( hYear – 3760, January, 1 )

A simple, albeit abstruse fixed-from-Gregorian function alternative that avoids adjusting for the month being after February and also avoids checking if it is a Gregorian leap year, is openly available on the internet – see the Calendrical Calculations: The Millennium Edition erratum for page 56 in reference 2, showing a simplified alt-fixed-from-gregorian function, which is openly available on the internet at <http://emr.cs.iit.edu/home/reingold/calendar-book/second-edition/errata.pdf>.

where hYear is the Hebrew year number, January = 1, and Start receives the fixed date of that Gregorian New Year Day.

However, I am not impressed with the idea of using anything to do with the Gregorian Calendar for this astronomical Hebrew calendar — it seems to me unnecessarily complicated, and it also limits the range of dates for which the function will operate correctly. One could use multiples of an assumed mean tropical year constant relative to an epoch, but the problem with that is that the Earth rotation rate is slowing down due to the tides, so again the range of dates for which the function will operate correctly is limited. My preference is to use my own mean orbital year (MOY) functions, as documented in the Symmetry454 Arithmetic documentation at this web site, which will allow the function to find a good starting moment over a wide range of dates. Passing an integer year number to my OrbitalDateToMoment function will cause it to compute the mean orbital new year moment, which is guaranteed to be within >74 to <83 days (average 78.55 days) of the target equinox. One could optionally add 74 or fewer days to start closer to the target equinox moment, but that won't improve the speed with which the CC3 solar-longitude-after function converges to the target equinox moment:

Start = OrbitalDateToMoment( hYear – 3760 )

The constant 3760 is again used because the astronomical Hebrew year in the vicinity of the mean orbital new year moment is 3760 years greater than the corresponding Orbital Date. Given the Start day or moment, the northward equinox moment is simply:

Equinox = solar-longitude-after( Start, spring )

where the constant spring = 0, which is the desired 0° solar longitude of the northward equinox. The solar-longitude-after function returns the Universal Time of the moment when the solar longitude equals the specified amount. It works by computing the solar longitude for the starting moment, comparing it with the target solar longitude, then making progressively finer stepwise changes to the moment that it is working with, recalculating the solar longitude at each step (a binary search) until it converges to within about a second of the target solar longitude, which is the desired equinox moment in this case. Although one could argue for using a much simpler mean equinox polynomial, such as given by Meeus in his book cited above, the CC3 solar-longitude function is needed anyway for the later sunset function, the solar-longitude-after function can operate over a much wider span of years than can a polynomial, and the complexity of the solar longitude calculations are quite tame in comparison with the lunar functions needed next.

To find the moment of the actual lunar conjunction (New Moon) prior to the equinox, in Universal Time, use the CC3 new-moon-before function, which returns the Universal Time of the prior New Moon moment:

Conjunction = new-moon-before( Equinox ) ' hop back to the previous New Moon, prior to the equinox

Starting at the New Moon before the equinox, find the first sunset that is at least ¹/₂ day after the actual lunar conjunction, which is the same as the sunset that is closest to 24 hours after the moment of the conjunction:

iter = 0 ' count the iterations through the loop, will use as a number of days offset after the conjunction, starting with same day

DO

SunsetThisDay = StandardToUniversal( sunset( Conjunction + iter, Jerusalem ), Jerusalem )

iter = iter + 1 ' get ready for next time around the loop

LOOP UNTIL SunsetThisDay – Conjunction > ¹/₂

Nisan1 = floor( SunsetThisDay ) + 1 ' bump day number to next fixed date, because for Hebrew dates it refers to the prior sunset

The CC3 sunset function returns the moment of sunset in Standard Time for the locale time zone, and the CC3 universal-from-standard function subtracts the time zone (2 hours) to convert that moment to Universal Time for direct comparison with the equinox moment.

The variable Nisan1 now equals the earliest possible fixed date for the first day of Nisan in the target year, but if the equinox lands after the first day of Passover then this is a leap year, in which case the first day of Nisan must get "bumped" to the next lunar conjunction. This case is determined by comparing the equinox moment with the moment of sunset at the beginning of the 16th of Nisan, which is the moment just after the first day of Passover ends, using the CC3 universal-from-standard and sunset functions for the locale of Jerusalem. If the equinox is too late then the start of Nisan must be delayed to the next lunar conjunction using the CC3 new-moon-after function (adding one week to be sure that new-moon-after starts its search from a day that is guaranteed to be after the unwanted lunar conjunction — performance is not improved by passing a value that is even closer to the next lunar conjunction), and then again the appropriate subsequent Jerusalem sunset using the same logic as above:

IF Equinox >= StandardToUniversal( sunset( Nisan1 + 14, Jerusalem ), Jerusalem ) THEN

Conjunction = new-moon-after( Nisan1 + 7 ) ' hop forward to the next New Moon, after the equinox (this is a leap year)

' Starting at the New Moon after the equinox, find the first sunset that is at least ¹/₂ day after the actual lunar conjunction,
' which is the same as the sunset that is closest to 24 hours after the moment of the conjunction:

iter = 0 ' count the iterations through the loop, will use as a number of days offset after the conjunction, starting with same day

DO

SunsetThisDay = StandardToUniversal( sunset( Conjunction + iter, Jerusalem ), Jerusalem )

iter = iter + 1 ' get ready for next time around the loop

LOOP UNTIL SunsetThisDay – Conjunction > ¹/₂

Nisan1 = floor( SunsetThisDay ) + 1 ' bump day number to next fixed date, because for Hebrew dates it refers to the prior sunset

END IF

When comparing with the equinox, the value + 14 is used rather than +16 because the Nisan1 value is already on day 1, adding 14 gives the 15th of Nisan, and it is the sunset at the end of the 15th of Nisan that is required. The new-moon-after function returns the Universal Time of the next New Moon moment.

Finally, the NisanFirstDay function returns the value of the fixed date that is in the variable Nisan1, which, for convenience in calendar calculations, is an integer that corresponds to civil midnight of the day that starts the month of Nisan. The actual evening of the first day of Nisan starts at the prior sunset.

By this method, the moment of sunset of the eve of the first day of Nisan in Jerusalem is uniformly distributed in the range from ¹/₂ to ³/₂ day after moment of the actual lunar conjunction. In about ²/₃ of years the new lunar crescent ought to be visible at that sunset in Jerusalem, and the crescent will always be visible at the next sunset.

The NisanFirstDay function keeps the first day of Passover within the Chodesh ha-Aviv limit between the equinox and 30 days later, as shown in this chart for the years 5700 to 5900 45 KB, and this is maintained over the long term, as shown in this chart for the years 4000 to 8000 135 KB.

Is it an Astronomical Hebrew Leap Year?

Given the Hebrew year number and a way to determine the fixed date of the first day of Nisan in any year, it is easy to determine if a year is non-leap (12 months) or leap (13 months). To check the leap status of a year, simply check the number of days separating its Nisan from the previous Nisan. If there too many days for a non-leap year then it is a leap year. The isAstroHebrewLeapYear function returns boolean TRUE if it is a leap year, or FALSE if it is a non-leap year:

As should be obvious from the isAstroHebrewLeapYear function definition, the NisanFirstDay function is called twice every time that the leap status of a year is checked. To enhance performance in routine calendar calculations, I recommend that the NisanFirstDay function should remember, as a minimum, its two most recently calculated Nisan1 fixed dates and their corresponding Hebrew year numbers, so that if either of the two most recently calculated values are again requested, it doesn't have to waste time recalculating, rather it can simply return the previously calculated value from memory. There would not be any performance benefit if only the single most recently calculated value were remembered, because the isAstroHebrewLeapYear function always asks for two years, which would "bump" each other unless both were remembered. When a different year is requested, it should "bump" the most recently calculated year into the second most recently calculated position, discarding the year that used to be in that second position. Of course, it might be worthwhile to "cache" the values for more years in transaction- or computation-intensive applications.

Leap years are the 2nd or 3rd year after the previous leap year. Therefore, when generating a leap year list, each time that a leap year is encountered the next year can be skipped to save processing time, because that next year can't possibly be a leap year:

For the 7 millennia tabulated above, the astronomical Hebrew calendar has an average of 368+²/₇ leap years, whereas the traditional Hebrew calendar has slightly more leaps at 368+⁸/₁₉ leap years per millennium. It is not valid to directly compare their average leap year intervals, however, because their calendar mean years are different and that of the astronomical calendar automatically varies over time.

The HopToNextMonth Function

After finding the fixed date of the first day of Nisan, calendar calculations need to be able to find the first day of all subsequent months until the next Nisan. This is not a trivial matter because each month can be 29 or 30 days long, depending on the duration of that lunar cycle and the timing of sunset after the next lunar conjunction. All months are located relative to the month of Nisan by "hopping" from month-to-month until the required month (or fixed date) is reached. The HopToNextMonth function calculates how much to "hop", returning the fixed date of the first day of the next month. It is called by the FixedToAstroHebrew and the AstroHebrewToFixed functions, below.

HopToNextMonth( MonthStart ) =

NextMonthStart = MonthStart + 29 ' provisionally set next month to start 29 days ahead

' Get the moment of the next actual lunar conjunction, starting one week after the given MonthStart.

Conjunction = NewMoonAfter( MonthStart + 7 )

' check the sunset at the end of the 29th day of the present month

Sunset29 = StandardToUniversal( sunset( NextMonthStart – 1, Jerusalem ), Jerusalem )

' If sunset at the end of the 29th day is less than ¹/₂ day after the conjunction, then make this a 30-day month, otherwise 29 days.

IF Sunset29 – Conjunction < ¹/₂ THEN RETURN NextMonthStart + 1 ELSE RETURN NextMonthStart

Even though this code segment for this function is very short and could have been repeated where necessary, I have found it convenient to have only one place to change when modifying the month-hopping strategy. This strategy is not the same as hopping from the vicinity of the lunar conjunction before the equinox to the vicinity of the next lunar conjunction, as done by the NisanFirstDay function above, because the latter can occasionally take a 31-day hop, whereas the month-to-month hop can never exceed 30 days. In other words, the NisanFirstDay function must check both Sunset29 and Sunset30 for each conjunction that it works with, whereas the HopToNextMonth function only needs to check Sunset29.

The ShiftRoshHaShanah Function

The Talmud Bavli tractate Rosh HaShanah page 20b indicates that in the days of the classical observational Hebrew calendar, to avoid having Rosh HaShanah land on Wednesday or Friday and thereby prevent Yom Kippur from occurring on either side of Shabbat (Friday or Sunday), which would be ritually inconvenient with regard to the burial of a corpse, the Sanhedrin calendar committee used to accept false or dubious witnesses to make Rosh HaShanah one day early, or they would intimidate valid witnesses to disqualify them or to get them to change their testimony or they would prolong the interviews (interrogations) until it was too late to sanctify that day as Rosh HaShanah to make Rosh HaShanah one day late. In the Talmud Bavli tractate Sukkah page 43a and also Talmud Yerushalmi tractate Sukkah page 4:5 it also says that Rosh HaShanah mustn't land on Sunday, which would cause Hoshanah Rabbah to land on Shabbat and thereby render the willow branches muktze (not to be touched on Shabbat) so they couldn't be ritually beaten to symbolize the final elimination of sins.

The traditional Hebrew calendar arithmetic employs Rosh HaShanah postponement rules that delay Rosh HaShanah if otherwise it would land on Wednesday, Friday, or Sunday, see: <http://individual.utoronto.ca/kalendis/hebrew/postpone.htm>.

Therefore a function is needed to adjust the fixed date of Rosh HaShanah in cases where it lands on a disallowed weekday, and this function will be used both in the conversion of a fixed date to an Astronomical Hebrew Date (see the FixedToAstroHebrew function, below) and in the conversion of an Astronomical Hebrew Date to a fixed date (see the AstroHebrewToFixed function, below). Given the fixed dates of the first day of Elul and the provisional Rosh HaShanah, the ShiftRoshHaShanah function returns the advanced, unchanged, or delayed fixed date of Rosh HaShanah.

The ShiftRoshHashanah logic checks if the provisional Rosh HaShanah is on a disallowed weekday. If it is a disallowed weekday, then if Elul has 29 days it returns the fixed date of Rosh HaShanah postponed one day later and Elul will be prolonged to 30 days, otherwise it returns the fixed date of Rosh HaShanah advanced one day earlier and Elul will be reduced to 29 days. Otherwise, when the provisional Rosh HaShanah is already on an allowable weekday, it returns that provisional fixed date unchanged:

ShiftRoshHashanah( ElulFirstDay, ProvisionalRoshHaShanah ) =

IF RoshHaShanahWeekday = YomRishon OR RoshHaShanahWeekday = YomRivii OR RoshHaShanahWeekday = YomShishi THEN

' Rosh HaShanah is provisionally on a disallowed weekday, so fix that...

IF ProvisionalRoshHaShanah – ElulFirstDay = 29 THEN ' if Elul has 29 days then prolong it to 30 days

RETURN ProvisionalRoshHaShanah + 1 ' postpone Rosh HaShanah to next weekday

ELSE ' otherwise Elul has 30 days, so shorten it to 29 days

RETURN ProvisionalRoshHaShanah – 1 ' advance Rosh HaShanah to previous weekday

END IF

ELSE ' otherwise leave Rosh HaShanah unchanged, it is already on an allowable weekday

RETURN ProvisionalRoshHaShanah

END IF

where YomRishon=1, YomRivii=4, YomShishi=6, and RoshHaShanahWeekday is calculated by dividing the fixed date by 7, keeping only the remainder, then incrementing that remainder to convert the result to Sunday=1 through to Saturday=7:

RoshHaShanahWeekday = ( ProvisionalRoshHaShanah MOD 7 ) + 1

When programming this function, be sure that the built-in MOD function of your computer language properly handles negative numbers (the MOD function of Microsoft Visual Basic is defective), otherwise it will yield incorrect weekday numbers for dates prior to the rata die epoch. If you have a defective MOD function, or are not sure, then 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 parameters provided both the x and the y parameter and the function return value are declared as Double Precision.

RoshHaShanahWeekday = modulus( ProvisionalRoshHaShanah, 7 ) + 1

On the astronomical Hebrew calendar, the Rosh HaShanah starting weekday frequencies are closer to equality than the traditional Hebrew calendar, which has Rosh HaShanah least commonly on Tuesday and most commonly on Thursday (which makes for a very long weekend with the High Holy Days on Thursday and Friday, then the Sabbath on Saturday), as shown in the next two tables:

The FixedToAstroHebrew Function

Given any CC3 fixed date, the FixedToAstroHebrew function converts the rata die to astronomical Hebrew calendar date. It can be used as the last stage of converting any other calendar date to its corresponding Astronomical Hebrew Date. Remember that throughout the execution of this function, Jerusalem must be the working locale.

One could start by estimating the Hebrew year, using the CC3 gregorian-year-from-fixed function as follows:

hYear = gregorian-year-from-fixed( FixedDate ) + 3760

For the reasons given above, however, I prefer to base the hYear estimate on the mean orbital year, using the function that is the inverse of the OrbitalDateToMoment function that we used above in the NisanFirstDay function, that is the MomentToOrbitalDate function:

hYear = floor( MomentToOrbitalDate( FixedDate ) ) + 3760

The Hebrew year hYear is correct if the fixed date is beyond the mean orbital new year moment but prior to the next Rosh HaShanah. If the fixed date is beyond the next Rosh HaShanah then hYear needs to be incremented, but the position of Tishrei is unknown until the first day of Nisan in hYear is found and then the calculation can "hop" forward from month-to-month until Tishrei. At this point it is impossible for the fixed date to be prior to the mean orbital new year moment of Orbital Year hYear + 3760, nor can it be later than the mean orbital new year moment of Orbital Year hYear + 3761.

Given the estimated hYear, calculate the fixed date of first day of Nisan of that year:

MonthStart = NisanFirstDay( hYear )

Next compare that MonthStart with the given fixed date, hopping forward from month-to-month until the correct month is reached. The easiest, albeit least likely, case is where the given fixed date just happens to correspond to the starting MonthStart value, so the calculation starts by defaulting hMonth to Nisan and then checking the fixed date. As specified in the Torah and Talmud, and as recommended for computer implementations by Dershowitz & Reingold in CC3, the astronomical Hebrew calendar months are numbered starting from Nisan = 1 to Tishrei = 7 to Adar = 12 and in leap years Adar1 = 12 and Adar2 = 13:

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, all done

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

hYear = hYear – 1

MonthStart = NisanFirstDay( hYear )

END IF

END IF

To review the above, if the fixed date matches the original first day of Nisan then the default month is correct and the procedure can skip down to calculation of the day number within Nisan. If the fixed date is after the beginning of Nisan then search forward from there. Otherwise the fixed date is prior to Nisan, so decrement the Hebrew year and use the NisanFirstDay function to get the fixed date of the previous first day of Nisan, which is guaranteed to be less than one Hebrew year prior to the unknown target date.

If the fixed date is after the original first day of Nisan then it must be prior to the next mean orbital new year moment, which is well before the astronomical Hebrew calendar leap month. In this case there is no need to know if hYear is a leap year.

If the fixed date is before the original Nisan then the calculation has jumped back to the previous Nisan, and the fixed date can't be equal to or later than the original Nisan. In this case, upon hopping forward from month-to-month if the calculation lands in the 13th month then that decremented hYear is a leap year, but again there is no need to check for that condition.

Hop forward from month-to-month using the rule that each month after Nisan starts after the 29th day of the previous month if the next actual lunar conjunction occurs closer to the end of that 29th day than the 30th day, otherwise it starts after the 30th day of the previous month:

DO

NextMonthStart = HopToNextMonth( MonthStart ) ' hop to the next month

IF hMonth = Elul THEN NextMonthStart = ShiftRoshHaShanah( MonthStart, NextMonthStart )

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

hMonth = hMonth + 1

IF hMonth = Tishrei THEN hYear = hYear + 1

MonthStart = NextMonthStart

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, let HopToNextMonth compute the fixed date of the first day of the next month.

A further adjustment of the NextMonthStart is necessary if the working month is Elul (Hebrew month number 6), because the next month starts with Rosh HaShanah and, depending on the weekday it lands on, that High Holy Day may be advanced or postponed. Recall that the ShiftRoshHaShanah function was defined above, and it handles any necessary adjustment to fixed date of Rosh HaShanah when hopping to or past the month of Tishrei. This adjustment is needed before checking against the given fixed date, otherwise the 30th of Elul could be incorrectly returned instead of an advanced 1st of Tishrei, or the 1st of Tishrei could be incorrectly returned instead of the 30th of Elul preceding a postponed Rosh HaShanah.

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:

hDay = FixedDate – MonthStart + 1

Having converted the given fixed date to a separated Astronomical Hebrew Date, with the year in hYear, the month in hMonth, and the day of the month in hDay, optionally the weekday of the fixed date can be determined in the same way that the provisional Rosh HaShanah weekday number was determined in the ShiftRoshHaShanah function given above, using the FixedDate value instead of ProvisionalRoshHaShanah:

Weekday = modulus( FixedDate, 7 ) + 1

The AstroHebrewToFixed Function

The AstroHebrewToFixed function converts any given Astronomical Hebrew Date to the corresponding CC3 fixed date. It can be used as the first stage of converting any Astronomical Hebrew Date to its corresponding date on any other calendar. It is also useful when one wishes to know how many days apart two Astronomical Hebrew Dates are, or when one wishes to know what will be the Astronomical Hebrew Date a certain number of days into the past or future. For example, to calculate the difference between two Astronomical Hebrew Dates:

IF hMonth >= Tishrei THEN hYear = hYear – 1

MonthStart = NisanFirstDay( hYear )

At this point the variable MonthStart has the CC3 fixed date of the Nisan that the search is going to start from, "hopping" from month-to-month until it reaches the given hMonth:

FOR Hop = Iyar TO hMonth ' if hMonth is Nisan then this FOR-NEXT loop will do nothing

NextMonthStart = HopToNextMonth( MonthStart )

IF Hop = Tishrei THEN NextMonthStart = ShiftRoshHaShanah( MonthStart, NextMonthStart )

MonthStart = NextMonthStart ' apply the fixed date of the next MonthStart

NEXT Hop

where Iyar=2 (don't start with Nisan because if the given month is Nisan then the FOR-NEXT loop will do nothing, since in that case the loop starting value of Iyar will be already past Nisan).

Recall that the ShiftRoshHaShanah function was defined above, and it handles any necessary adjustment to the fixed date of Rosh HaShanah when hopping to or past the month of Tishrei. After execution of the above FOR-NEXT block, the variable MonthStart has the fixed date of the first day of the given 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

Note that as written, if the user specifies an hDay=30 for an Astronomical Hebrew 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 to handle that condition. This also works even in the case of the 30th of Elul where Rosh HaShanah is advanced — the returned fixed date will be that which corresponds to the 1st of Tishrei of the next civil year. If an excessively large day number is passed, for example requesting the 35th day of a month, then the returned date will correspond to the 5th or 6th day of the next month, depending on the length of the specified month. Similarly, if the user specifies Adar2 for a non-leap year then the returned date will correspond to Nisan, or if a silly month number is passed, such as 15, then the hopping from month-to-month will continue until that month is reached.

Checking if a Date is Valid

To check if an astronomical Hebrew calendar date exists, which may be useful to know for the 30th of any month or for all dates in the month of Adar 2, it it 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 date that returns is the same as the original date, then the original date exists. Here is an example of such an AstroHebrew-to-Fixed-to-AstroHebrew procedure:

FixedDate = AstroHebrewToFixed( hYear1, hMonth1, hDay1 )

Then use FixedToAstroHebrew( FixedDate ) to convert back to hYear2, hMonth2, and hDay2, and finally verify that what comes back matches the original date:

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

The boolean variable DateExists is set to TRUE if the original date is a valid astronomical Hebrew calendar date, or FALSE otherwise. Of course if one is wondering about the first 29 days of Adar 2, simply checking if it is a leap year will indicate whether those dates exist, but doesn't indicate if the 30th of Adar 2 exists. The AstroHebrew-to-Fixed-to-AstroHebrew procedure given above, however, is generically convenient for checking any date.

Comparing Hebrew Calendars

The traditional Hebrew calendar month lengths are all fixed except for Cheshvan and Kislev, whereas any astronomical Hebrew calendar month can be 29 or 30 days. If one compares the corresponding dates on the traditional Hebrew calendar with those of the astronomical Hebrew calendar, they are astonishingly close — when they agree on the leap cycle, most often the Astronomical is on the same day or the day before or after.

When the two calendars disagree on the leap year status, then as soon as the leap month is inserted the calendar that did not leap will be one month further ahead, until it also inserts a leap month (usually by the next year). Although both calendars employ intervals of either 2 or 3 years between leap years, the astronomical Hebrew calendar has 368 leap years per millennium, whereas the traditional Hebrew calendar has 368+⁸/₁₉. It is not valid to directly compare their average leap year intervals, because their calendar mean years are different, and because the leap year interval of the astronomical calendar is automatically adjusted to maintain drift-free alignment with the predicted moment of the northward equinox.

Nevertheless, with regard to the moment of sunset at the beginning of the 16th of Nisan, the average difference between the two calendars at present is 7 days, such that the earliest that Nisan 16 starts on the traditional Hebrew calendar is 7 days after the northward equinox and the latest start 37 days after the equinox (or 7 days beyond the Chodesh ha-Aviv limit), whereas on the astronomical Hebrew calendar the earliest Nisan 16 dates start right where they ought to be, just after the equinox moment, and the latest are within the Chodesh ha-Aviv limit, never exceeding 30 days after the equinox.

The traditional Hebrew calendar Rosh HaShanah of 5766 was exceptionally late, because 5765 was a leap year and also was the 8th year of the 19-year cycle (the 8th year is always the latest, every 19 years), on Gregorian Tuesday, October 4th, postponed by one day relative to the molad moment, yet the new lunar crescent will not be seen at Jerusalem until the 3rd of Tishrei. The astronomical Hebrew calendar, which did not make 5765 a leap year, had Rosh HaShanah 5766 on Gregorian Tuesday, September 6th, and its New Year Day was neither advanced nor postponed.

This chart graphically depicts the elapsed time of Rosh HaShanah with respect to the actual astronomical lunar conjunctions (89 KB), showing slight changes over the millennia, and also summarizes the Rosh HaShanah advance/postpone and weekday frequences, and year length frequencies. Contrast that with the same type of chart for the traditional Hebrew calendar (96 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).

Lunar Cycle Alignment

The molad of the traditional Hebrew calendar is drifting late, because the fixed molad interval is now about ²/₃ second longer than the actual mean duration of lunations (mean synodic month). The mean synodic month is continuing to get shorter at a steady rate of about ¹/₃ mean solar second per thousand years, due to tidal slowing of the Earth rotation rate, which was not recognized until the beginning of the 20th century and then was accurately measured only after the advent of Atomic Time (1955) and Laser Lunar Ranging (1969). This progressive shortening of the mean synodic month is causing an accelerating lateward drift of the molad, such that future moladot will occur at progressively later moments with respect to the actual mean lunar conjunctions. In the era of Hillel ben Yehudah, Hebrew year 4119 = Julian 358 AD), the molad of Tishrei was about 4+¹/₅ hours later than the actual mean lunar conjunctions. In the present era that molad is about 6 hours late, by Hebrew year 8000 it will be 11+³/₄ hours late, and by year 10000 it will be about 21+¹/₃ hours late. The probability of the crescent being visible on Rosh HaShanah (or on the first day of any month, especially for months that follow a postponed Rosh HaShanah) progressively increases as the molad gets later and later with respect to the actual lunar conjunctions. Please see my analysis of the molad drift, what is causing it, how it varies between months and over the years, and what can be done to adjust the molad arithmetic, please see my astronomical analysis of the traditional molad at <http://individual.utoronto.ca/kalendis/hebrew/molad.htm>.

The astronomical Hebrew calendar, however, is drift-free with respect to the lunar cycle (limited only by the underlying astronomical algorithms, which are upgradeable), because it determines the actual lunar conjunction moment and starts each month at the sunset after the conjunction, or the following sunset if the conjunction is past Noon in Jerusalem — this is the same as saying that the month starts at the Jerusalem sunset that is closest to 24 hours after the actual lunar conjunction.

If, before any shift is applied, Rosh HaShanah of a 30-day Tishrei occurs on a disallowed weekday after a 30-day Elul, then it would be advanced one day earlier. This would cause the following Cheshvan to also begin one day early and/or the following Kislev and/or possibly Tevet may also begin a day early. There is no danger, however, of this shift propagating through to cause the month before the next Nisan (Adar or Adar Sheini) to have 31 days — I have verified for Hebrew years 3001 through 10000 that the first day of Shevat, Adar or Adar Rishon, and Adar Sheini always starts on the first day of predicted visibility of the new lunar crescent.

By the third day of any astronomical Hebrew calendar month, it is extremely rare the crescent to still not be seen — just the occasional postponed Tishrei, only 2 or 3 times per millennium. Again, despite the progressive drift of the molad later and later with respect to the actual mean lunar conjunctions, the traditional Hebrew calendar will continue to have a higher frequency of lunar crescent still not visible by the start of the third day of Av and Tishrei even into the 9th millennium.

All of the above crescent visibility tables are available in PDF format for the astronomical Hebrew calendar 48KB and for the traditional Hebrew calendar 56KB.

Nevertheless, from the tables above, for the 1000 years from 5001 to 6000, the crescent ought to be visible in Jerusalem at sunset at the beginning of the eve of Rosh HaShanah in almost 40% of years, which is much higher than the traditional Hebrew calendar rate of about 18% for the first day of Rosh HaShanah 71KB). By the time of the second sunset in Tishrei the crescent ought to be visible in about 85% of years, also much higher than the present Hebrew calendar rate of about 60%. This seems very promising.

Solar Cycle Alignment

At the time of Hillel ben Yehudah in Hebrew year 4119, the original alignment of the traditional Hebrew calendar had the beginning of Nisan in the first year of each 19-year cycle aligned at the northward equinox, so 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. 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 the advent of 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 drift of the equinox is accelerating, 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 equinox drift 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 accelerating equinox drift please see my "Lengths of the Seasons" web page.

The astronomical Hebrew calendar, however, is drift-free with respect to the northward equinox (limited only by the underlying astronomical algorithms, which are upgradeable), always keeping the end of the first day of Passover nicely aligned somewhere within the Chodesh ha-Aviv limit band between the equinox and 30 days later, as shown in this chart for the years 5700 to 5900 44 KB, and the excellent alignment is maintained over the long term, as shown in this chart for the years 4000 to 8000 134 KB.

It is not possible to simultaneously align a calendar to both equinoxes, because their respective equinoctial year lengths are different and change at different rates (see my web page "The Lengths of the Seasons" at <http://individual.utoronto.ca/kalendis/seasons.htm>). For this astronomical Hebrew calendar this chart shows its long-term alignment relative to the southward equinox for the years 4000 to 8000 227 KB.

Variants of this Astronomical Hebrew Calendar

The astronomical Hebrew calendar presented above is what I consider to be the best or the ritually or socially preferable implementation so far. I will briefly discuss the features of other versions, explaining why I have abandoned some of them:

Sunset at First Visible Crescent: This calendar started Nisan at the sunset when the new lunar crescent was predicted to first be visible in Jerusalem. Each month thereafter starts 29 days later if the crescent is predicted to be visible, otherwise on the next day. Abandoned because of the controversy and uncertainty surrounding calculation of the visibility of the crescent. As mentioned above, the visibility criteria are optimistic even for ideal observing conditions. I believe that it would be futile to return to this strategy even with more realistic visibility criteria, because validation would be onerous and controversial.
Sunset Nearest Conjunction: This variant starts Nisan at the Jerusalem sunset closest to the moment of the actual lunar conjunction (±¹/₂ day), which is easily calculated to sub-minute accuracy. Each subsequent month starts at the sunset 29 or 30 days later, whichever is closest to the next lunar conjunction. Abandoned because starting months so near to the conjunction had the effect that the new lunar crescent was rarely visible on the first and most often not even on the second day of the month, which would probably be socially unacceptable.
Sunset Nearest Conjunction + 24h: As documented herein, starts Nisan at the Jerusalem sunset closest to 24 hours after the moment of the actual lunar conjunction.
Conjunction + ⁷/₄d or +2d: This performance of this variant is almost identical to #3 documented herein, but the arithmetic is much simpler, not requiring the moment of sunset for determining the first day of the month. Instead the fixed date of the first day of a month is determined by adding ⁷/₄ day to the Jerusalem mean solar time moment of the actual lunar conjunction moment, then discarding the fraction. The alternative offset of +2 days is also promising.
Adjusted Molad (Actual MEAN Conjunction) + ⁷/₄d or +2d: Like #4 above, but replaces the complex algorithm for the actual lunar conjunction with a relatively trivial fixed arithmetic formula for the actual mean lunar conjunction, based on my Average Adjusted Molad arithmetic, as discussed on my Proposed Molad Adjustment Equations web page.
Adjusted Molad + ⁵/₄ days: Like #5 above, but uses a 30-hour conjunction offset because that yields the highest frequency of identical months in comparison with the traditional Hebrew calendar.
130/353 Fixed Arithmetic Leap Cycle with Traditional or Adjusted Molad: Evaluation complete, please seek separate web page entitled The Rectified Hebrew calendar. This fixed arithmetic variant will maintain good alignment with the equinox until beyond Hebrew year 10000 (>4 millennia into the future) if the traditional molad is employed, but employing the progressive molad, which has a progressively shorter molad interval, will extend it by an extra 3 millennia to beyond Hebrew year 13000 (>7 millennia into the future).
Future Hebrew Calendar based on 100-Saros fixed arithmetic solar cycle in parallel with 4 repeats of the 25-Saros fixed arithmetic lunar cycle: simpler arithmetic than the Rectified Hebrew calendar. Exceptionally short calendar full repeat interval of only 1803 years (658532 days), equal to the number of years per cycle, with 664 leap months per cycle for a total of 22300 months per cycle = 100 × the well-known 223-month saros eclipse interval. Mean year = 365+⁴³⁷/₁₈₀₃ days = 365d 5h 49m 1+⁵⁹/₆₀₁s, which is a good approximation to the current astronomical mean northward equinoctial year. Mean month = 29+²⁹⁵⁸/₅₅₇₅ days = 29d 12h 44m 2+⁸²/₂₂₃s, which is intentionally a tad short relative to the mean synodic month to maximize the long-term utility of the lunar cycle. The denominator implies a lunar cycle of 5575 months, which equals 25 saros intervals or exactly ¹/₄ of the 100-saros solar cycle. A parallel solar calendar could have 437 leap days or 320 leap weeks per cycle to obtain exactly the same calendar mean year. For best astronomical correlation this variant requires a future epoch, at least for the lunar cycle, perhaps around Hebrew year 8000.

The objective for this project was to continue to simplify the calendar calculations through a series of stages, ultimately finishing with a fixed arithmetic calendar that for as long as possible into the future will closely approximate the performance of a reference astronomical calendar, remaining drift-free for as long as possible with respect to the actual solar and lunar cycles. This goal was completed, please see the Rectified Hebrew calendar web page.

CC3 Function Name	Description
floor	returns the integer portion of a real number
modulus	returns the remainder from a division operation
universal-from-standard	converts a Universal Time moment to Standard zone time
fixed-from-Gregorian	converts a separated Gregorian date to a fixed date (or use the alternative alt-fixed-from-Gregorian)
gregorian-year-from-fixed	returns the Gregorian year number that contains the specified fixed date
solar-longitude	returns the solar longitude at a specified moment
solar-longitude-after	returns the moment when the solar longitude will equal the specified amount after the specified moment (typically used to find an equinox or solstice)
sunset	returns the standard time of sunset on the specified fixed date, in the specified time zone
new-moon-before	returns the moment of the nearest lunar conjunction prior to the specified moment
visible-crescent	returns TRUE if the new lunar crescent is predicted to be visible at the sunset prior to the specified fixed date (optional, not required for the calendar arithmetic, only for evaluating its astronomical performance)
new-moon-after	returns the moment of the nearest lunar conjunction after the specified moment

Year Range	Non-Leap Years			Leap Years
	353 days	354 days	355 days	383 days	384 days	385 days	Number of Leap Years
	Deficient	Normal	Full	Deficient	Normal	Full	Number of Leap Years
3001-4000	0	388	243	49	320	0	368
4001-5000	0	391	241	48	318	2	369
5001-6000	0	400	232	42	322	4	368
6001-7000	0	408	224	36	326	6	368
7001-8000	0	408	223	36	326	7	368
8001-9000	2	407	223	33	329	6	369
9001-10000	2	402	227	36	328	5	368

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

Year Range	Advanced	No Shift	Postponed	Monday	Tuesday	Thursday	Saturday
3001-4000	238	547	215	237	211	284	268
4001-5000	180	604	216	233	202	272	293
5001-6000	163	645	192	196	201	292	311
6001-7000	210	613	177	192	213	309	286
7001-8000	248	552	200	188	246	288	278
8001-9000	264	504	232	208	246	271	275
9001-10000	244	501	255	238	209	284	269

Year Range	No Shift	Delayed 1	Delayed 2	Monday	Tuesday	Thursday	Saturday
4001-5000	252	505	243	277	116	318	289
5001-6000	248	505	247	282	114	319	285
6001-7000	248	505	247	280	117	316	287
7001-8000	245	506	249	280	114	323	283
8001-9000	241	508	251	280	115	318	287
9001-10000	245	507	248	278	116	318	288

Year Range	Length of Elul		Length of Tishrei
	29 days	30 days	29 days	30 days
	Deficient	Full	Deficient	Full
3001-4000	477	523	454	546
4001-5000	434	566	487	513
5001-6000	460	540	468	532
6001-7000	538	462	433	567
7001-8000	563	437	454	546
8001-9000	551	449	489	511
9001-10000	511	489	530	470

Year Range	*Nisan*	*Iyar*	*Sivan*	*Tammuz*	Av	*Elul*	*Tishrei*	*Cheshvan*	*Kislev*	*Tevet*	*Shevat*	*Adar*	*Adar2*
3001-4000							29
4001-5000							37
5001-6000							37	3
6001-7000							42	3
7001-8000							42	6
8001-9000							41	3
9001-10000							44	5

Year Range	*Nisan*	*Iyar*	*Sivan*	*Tammuz*	Av	*Elul*	*Tishrei*	*Cheshvan*	*Kislev*	*Tevet*	*Shevat*	*Adar*	*Adar2*
3001-4000	304	318	345	409	535	622	624	672	577	446	337	313	123
4001-5000	287	303	334	420	539	631	609	635	573	409	346	310	108
5001-6000	292	310	333	416	532	623	614	604	552	426	346	299	113
6001-7000	291	302	335	411	542	635	646	621	561	423	342	309	109
7001-8000	299	313	344	418	543	622	633	634	562	429	345	319	118
8001-9000	311	312	336	438	544	627	624	628	557	438	354	325	123
9001-10000	328	338	361	432	542	628	589	613	545	440	363	329	126

Year Range	*Nisan*	*Iyar*	*Sivan*	*Tammuz*	Av	*Elul*	*Tishrei*	*Cheshvan*	*Kislev*	*Tevet*	*Shevat*	*Adar*	*Adar2*
4001-5000	740	541	713	517	754	590	839	654	717	537	808	593	191
5001-6000	706	467	729	493	792	588	835	633	642	512	745	557	138
6001-7000	687	430	742	501	774	588	787	573	558	450	693	491	135
7001-8000	644	405	671	482	710	528	725	473	426	334	607	390	134
8001-9000	514	307	555	373	643	438	679	383	307	229	505	288	97
9001-10000	353	157	448	249	582	348	590	293	242	143	371	167	20