The motives and design goals for developing this experimental astronomical Hebrew calendar are:
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 1/2 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 1/2 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".
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:
|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|
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.
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://www.sym454.org/symmetry/>. 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.
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.
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:
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 1/2 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 1/2 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 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 1/2 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
SunsetThisDay = StandardToUniversal( sunset( Conjunction + iter, Jerusalem ), Jerusalem )
iter = iter + 1 ' get ready for next time around the loop
LOOP UNTIL SunsetThisDay – Conjunction > 1/2
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 1/2 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
SunsetThisDay = StandardToUniversal( sunset( Conjunction + iter, Jerusalem ), Jerusalem )
iter = iter + 1 ' get ready for next time around the loop
LOOP UNTIL SunsetThisDay – Conjunction > 1/2
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 1/2 to 3/2 day after moment of the actual lunar conjunction. In about 2/3 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.
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:
The comparison value of 365 days is convenient but not critical. Any value that is guaranteed to be greater than the length of a non-leap 12-month Hebrew year and less than the length of a leap 13-month Hebrew year would work just as well. The possible year lengths of the astronomical Hebrew calendar (measured from the first day of Nisan, because the calendar is fixed relative to the northward equinox and the first visible new lunar crescent of Nisan) are the same as the legal year lengths of the traditional Hebrew calendar (measured from Rosh HaShanah, because that calendar is fixed relative to the molad of Tishrei): non-leap years can have 353 or 354 or 355 days, and leap years can have 383 or 384 or 385 days.
It so happens that on the astronomical Hebrew calendar the shortest possible 353-day ("deficient" non-leap) years are very rare (in fact, none will occur until the 9th millennium), as are the longest possible 385-day ("full" leap) years. Non-leap years are almost twice as likely to be "normal" rather than "full", whereas leap "normal" years are are presently about 7 2/3 times (increasing to >9 times by the 10th millennium) more common than "deficient" leap years:
|Year Range||Non-Leap Years||Leap Years|
|353 days||354 days||355 days||383 days||384 days||385 days||Number
The fact that 353-day and 385-day years occur at all is because this astronomical Hebrew calendar employs the actual lunar conjunctions and allows any month to be 29 or 30 days.
Compare the table above with the traditional Hebrew calendar year length frequencies (measured from Rosh HaShanah as explained above), which has about half as many "deficient" non-leap years and about equal frequencies of "normal" and "full" non-leap years, and for leap years the "deficient" and "full" lengths are about equally likely and each about 3 times more common than "normal" leap years, as shown in the table below:
Year Length Frequences of the Traditional Hebrew Calendar
(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|
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 hYear = StartYear TO EndYear
IF isAstroHebrewLeapYear( 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
For the 7 millennia tabulated above, the astronomical Hebrew calendar has an average of 368+2/7 leap years, whereas the traditional Hebrew calendar has slightly more leaps at 368+8/19 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.
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 1/2 day after the conjunction, then make this a 30-day month, otherwise 29 days.
IF Sunset29 – Conjunction < 1/2 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 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://www.sym454.org/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
ELSE ' otherwise leave Rosh HaShanah unchanged, it is already on an allowable weekday
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:
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:
Astronomical Rosh HaShanah Shift Frequency and Weekdays
(number of years per 1000 years, disallowed weekdays are Sunday, Wednesday, Friday)
|Year Range||Advanced||No Shift||Postponed||Monday||Tuesday||Thursday||Saturday|
Traditional Rosh HaShanah Postponements and Weekdays
(number of years per 1000 years, disallowed weekdays are Sunday, Wednesday, Friday)
|Year Range||No Shift||Delayed 1||Delayed 2||Monday||Tuesday||Thursday||Saturday|
On the traditional Hebrew calendar the lengths of the months Elul and Tishrei are permanently fixed at 29 and 30 days, respectively. On the astronomical Hebrew calendar, however, the lengths of the months Elul and Tishrei can have 29 or 30 days, approximately evenly split between the two month lengths. Of course, due to the Rosh HaShanah advance/postpone rule, when Elul has 29 days Tishrei has usually 30 days, and when Elul has 30 days Tishrei usually has 29 days. The assertion that is the most frequent calendar-related dictum in the Talmud, however, holds that Elul will be deficient "in most years", in fact the Talmud Bavli tractate Beitzah page 22b says "From the days of Ezra and onward we never find Elul intercalated.", even though such a policy must conflict with the practise of avoiding Sunday, Wednesday, and Friday as the first day of Rosh HaShanah. Nevertheless, on the astronomical Hebrew calendar Elul is full in more than 54% of the years from 3001 to 6000:
|Year Range||Length of Elul||Length of Tishrei|
|29 days||30 days||29 days||30 days|
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 )
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:
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
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 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:
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 Astronomical Hebrew Date:
OffsetDate = AstroHebrewToFixed( hYear, hMonth, hDay ) + Offset
Then use FixedToAstroHebrew ( OffsetDate ) function to determine the desired Astronomical Hebrew Date.
For dates in Nisan through Elul, hop from month-to-month starting from Nisan of the given Hebrew year, but for dates in Tishrei through Adar2 search from the Nisan of the previous Hebrew year:
IF hMonth >= Tishrei THEN hYear = hYear – 1
MonthStart = NisanFirstDay( hYear )
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
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.
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.
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+8/19. 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).
The molad of the traditional Hebrew calendar is drifting late, because the fixed molad interval is now about 2/3 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 1/3 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+1/5 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+3/4 hours late, and by year 10000 it will be about 21+1/3 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://www.sym454.org/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.
Astronomical Hebrew Calendar — New Lunar Crescent Already Visible on Day Before Month
(number of years per 1000 years — just the occasional advanced Tishrei and rarely its next Cheshvan, remaining about the same in future years)
Traditional Hebrew Calendar — New Lunar Crescent Already Visible on Day Before Month
(number of years per 1000 years — overall, already visible in about 5% of all months at present, but increasing to almost 22% by the 10th millennium)
It is clear from the above table that the traditional Hebrew calendar has a much higher rate of premature crescent visibility, and this problem will get much worse in the future as the moments of the moladot drift later and later. The astronomical Hebrew calendar calculates the moment of the actual lunar conjunction, usually starting the month at the sunset after that conjunction, or the following sunset, thus the new lunar crescent will rarely be visible prematurely, and that performance will continue indefinitely, limited only by the underlying lunar astronomical algorithms.
Astronomical Hebrew Calendar — New Lunar Crescent Not Yet Visible on First Day of Month
(number of years per 1000 years — overall, visible on first day in about 55% of all months, remaining about the same in future years)
Most of the above "early" months have 30 days except that most of those in Elul are shorted to 29 days by advancement of Rosh HaShanah. Almost all "early" Tishrei months have Rosh HaShanah advanced early by one day to avoid a disallowed weekday. As expected, most of the early Cheshvan and all of the "early" Kislev and Tevet months are "downstream" of a Rosh HaShanah advanced earlier by one day.
The long-term trend of steadily improving crescent visibility rate for Tishrei, Cheshvan, Kislev, and Tevet is fascinating, but I have not yet determined the reason(s). Possibilities include slow but steady astronomical changes over the coming millennia such as progressive shortening of the mean synodic month and of the northward equinoctial year, and the slow drift of the Earth orbital aphelion to dates that will be progressively closer to Tishrei. Aphelion is currently in Tammuz, causing the average duration of the lunar cycle to be appreciably shorter during Tammuz, Av, and Elul, which explains the greater tendency of those months to start "early". Aphelion is slowly approaching Tishrei but will not reach Rosh HaShanah until the 13th millennium.
Traditional Hebrew Calendar — New Lunar Crescent Not Yet Visible on First Day of Month
(number of years per 1000 years — overall, visible on first day in almost 40% of all months at present, increasing to almost 70% by the 10th millennium)
In the present era the astronomical Hebrew calendar has a substantially higher rate of lunar crescent visibility than the traditional Hebrew calendar, even though the astronomical has a much lower frequency of premature crescents. The astronomical first day crescent frequency will remain steady over the millennia, whereas the traditional first day crescent frequency will progressively increase as the molad drifts later and later at an accelerating rate.
Astronomical Hebrew Calendar — New Lunar Crescent Still Not Visible on Second Day of Month
(number of years per 1000 years — overall, visible on second day in almost 98% of all months, remaining about the same in future years)
Traditional Hebrew Calendar — New Lunar Crescent Still Not Visible on Second Day of Month
(number of years per 1000 years — overall, visible on second day in more than 80% of all months at present, increasing to almost 97% by the 10th millennium)
The astronomical Hebrew calendar has nearly complete lunar crescent visibility by the second day of any month, although Tishrei or Cheshvan may occasionally lack a crescent associated with postponement of Rosh HaShanah to avoid a disallowed weekday. Even with 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 second day of most months even beyond the 9th millennium.
Astronomical Hebrew Calendar — New Lunar Crescent Still Not Visible on Third Day of Month
(number of years per 1000 years — overall, visible on third day in >99.9% of all months, only rarely missing an advanced Tishrei, about the same in future years)
Traditional Hebrew Calendar — New Lunar Crescent Still Not Visible on Third Day of Month
(number of years per 1000 years — overall, visible on third day in more than 99% of all months at present, increasing to almost 100% by the 10th millennium)
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.
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.
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://www.sym454.org/seasons/>). 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.
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:
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.
Updated 10 Nisan 5771 (Traditional) = 10 Nisan 5771 (Rectified) = Apr 11, 2011 (Symmetry454) = Apr 11, 2011 (Symmetry010) = Apr 14, 2011 (Gregorian)