The Rectified Hebrew Calendar

by Dr. Irv Bromberg, University of Toronto, Canada

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

Comments and Suggestions Received

The following are major comments and suggestions received to date, and their status:

#	Status	Description and Discussion
0.	Rejected (for now)	For the progressive molad, use the "Full Moon Cycle" (FuMoCy) approximation to account for the major periodic variations of the actual lunar cycle. Rejected because this would go far beyond restoring the molad to its original state, the arithmetic is significantly more complicated, those periodic variations will get transferred into the calendar arithmetic thus making the calendar less uniformly regulated, and although the FuMoCy approximation as currently specified provides a good fit in the present era, it will get "out of sync" with the actual lunar cycle in only a few hundred years. This idea could be reconsidered if a way to improve long-term synchrony is found. Meanwhile, the Rosh HaShanah postponement rules used in the HebrewNewYear353 function are now compatible with the periodically variable-length molad intervals that FuMoCy approximation would cause.
1.	Done	The molad weekday was one day too early when the molad moment was past 18:00h (nominally, sunset). Adding 6 hours to the molad epoch corrected this, and required also changing the molad offset from +30 to +24 hours (therefore no change in any Rectified Hebrew Calendar dates), and recalculation of the Rosh HaShanah postponement and weekday frequencies for the Traditional Hebrew calendar.
2.	Done	Simplify the progressive molad arithmetic by using calculus (a simple quadratic expression) to integrate the area under the trend line for the length of the mean synodic month. The resultant more accurate progressive molad yields essentially the same dates in the present era, but some distant future dates change. Updated most of the Rectified Hebrew Calendar evaluation charts and statistical tables.
3.	Not Worthwhile Now, Reconsider Later	Align the month of Nisan relative to a solar calendar leap cycle instead of the 130/353 leap month cycle. This is not a useful suggestion because the arithmetic to do so is appreciably more complicated than using the much more direct 130/353 leap month cycle, no solar leap cycle can keep the equinox better aligned, and because no fixed arithmetic solar leap cycle will be able to maintain excellent equinox alignment for as long as will the 130/353 leap month cycle with progressive molad. Although the progressive linear approximation leap rule for the Northward Equinox year (LANEY) is predicted to last much longer, for the next 7 millennia LANEY has no advantage over the simpler 130/353 leap month cycle.
4.	In Progress	Add examples for each calculation.
5.	Done	Recalculate traditional molad minus actual new moon based on two widely separated solar eclipses at lunar perigee, fit quadratic, calculate minimum difference and lunation number at vertex, and directly use the quadratic as the progressive molad adjustment.
6.	Fixing Elul at 29 days is included in #7, below	The Talmud frequently mentions that the month of Elul almost always had 29 days, because Moses ascended Mount Sinai on the first day of Elul and came down with the tablets bearing the Ten Commandments 40 days later, on Yom Kippur. Elul of the Traditional Hebrew Calendar always has 29 days. Fixing the Rectified Hebrew Calendar length of Elul at 29 days shifts Rosh HaShanah an average of ¹/₂ day earlier with respect to the actual lunar conjunction of Tishrei, but it is easy to compensate for that by also fixing Av at 30 days, and then the length of Tammuz can vary to handle the Rosh HaShanah advance/postpone rule.
7.	Done	Allowing any month to have 29 or 30 days, and the Rosh HaShanah advance/postpone rule are innovative (with or without also fixing the lengths of Av and Elul), but these strategies may be in conflict with long-standing traditions regarding fixed day counts between certain holidays, and the traditionally possible weekdays for certain holidays. Instead, fix month lengths according to the same rules as used for the Traditional Hebrew Calendar, including the traditional Rosh HaShanah postponement rules.
8.	Done	For the progressive molad calculus method, as an alternative to integrating from near the Hebrew Calendar epoch (extrapolated 4000 years before the start of the perigee eclipse study), use the vertex (minimum) of the molad adjustment parabola as the integration epoch.
9.	Done	Unify the arithmetic of the Rectified and Traditional Hebrew calendars so that the same set of functions can perform calculations for either calendar, depending on a specified calendar mode.
10.	Low Priority	Also merge the Astronomical Hebrew Calendar functions into the unified Rectified and Traditional Hebrew calendar arithmetic. The problem with this idea is that the astronomical algorithms depend on functions from CC3 and AA which are not open-source, not in the public domain.
11.	Done	Calculate relative to the J2000.0 epoch instead of the rata die epoch, for improved resolution of times-of-day relative to the present era when using floating-point arithmetic. The present version of Kalendis now allows the user to pick any epoch for fixed day numbering, with the beginning of the 3rd millennium (January 1, 2001 AD) as the default.
12.	Under Consideration	Post the Microsoft Visual Basic 6 source code for the calendar arithmetic functions. Not as broadly useful as the Mathematica source code, see next.
13.	Must Do This	Post the Mathematica source code for the calendar arithmetic functions, to serve as an unambiguous and absolutely accurate reference for verifying other implementations, executable using the freeware MathReader on almost any computing platform. Any volunteer willing to do this? (contact me)
14.	Maybe	Post the LISP source code, using arbitrary-precision exact arithmetic. Any volunteer willing to do this? (contact me)
15.	Rejected	Redo the molad eclipse study with the following enhancements: Round the difference between the actual lunar conjunction and traditional molad moment to the nearest second so that Mathematica has only integers to work with when fitting the curve. Include both the starting and ending eclipse in the curve fit (they should both be very close to the long-term average anyway). Pick a starting eclipse that was several more centuries earlier than the era of Hillel ben Yehudah. Pick maximum duration total solar eclipses at lunar perigee that are as close as possible to the longitude of the contemporary Earth orbital aphelion and visible near Earth's equator (typically the longest duration total solar eclipse of any given Saros series). Ideally the two eclipses should be at the same lunar orbital node (ascending or descending) so that they will be separated by an integer number of draconic months, anomalistic months, and triple-Saros cycles. Include graphical chart "close-ups" of the both ends of the study interval, to show the relation of the curve fit to the periodicity of the lunar cycle. Consider rounding the progressive molad moment to either the nearest second or nearest part. see also suggestions 23 and 24, below. Rejected because the technique developed for #24 makes further eclipse studies unnecessary, and because the desired more accurate molad arithmetic will be based on SOLEX numerical integration, see #26.
16.	Rejected	Pick two total solar eclipses, both visible at Jerusalem. This is an aesthetically attractive suggestion. Within ±2000 years of the present era I found only two eclipses that move across central Israel from west to east, seemingly ideal because even with a Delta T approximation error Jerusalem would still be in the total eclipse path. The past eclipse shown in this NASA chart <http://eclipse.gsfc.nasa.gov/SEatlas/SEatlas-1/SEatlas-0339.GIF> crossed Israel shortly before noon, and reached maximum totality midway between Israel and Babylonia! (The actual location of the maximum depends on the true Delta T for that moment, which we may never know unless a written record of that eclipse is found.) The future eclipse shown in this chart <http://eclipse.gsfc.nasa.gov/SEatlas/SEatlas3/SEatlas2541.GIF> will cross Israel early in the morning, reaching maximum totality near Bangladesh. Rejected because neither of these eclipses was/will be close enough to lunar perigee and Earth orbital aphelion to yield ideal timing relative to the periodicity of the lunar cycle.
17.	Rejected	Instead of molad adjustment, use the latest Chapront polynomial for the Delaunay "D" parameter (mean lunar elongation = mean lunar phase), which includes the lunar acceleration rate derived from Laser Lunar Ranging, coupled with a parabola that approximates Delta T. The polynomial seems to better fit the actual conjunctions without its physically implausible 3rd and 4th order terms. If adopted, would replace the progressive molad with the mean lunar conjunction, discontinuing the concept of a molad adjustment. Rejected because this polynomial is very badly behaved outside of its valid range. Any revision of the progressive molad will be based on numerical integration.
18.	Rejected	Instead of using the analytical astronomical algorithms of Chapront et al, and Meeus (derived from the IMCCE), use the integrations of the Jet Propulsion Laboratory, which are considered the most accurate available, for developing the progressive molad approximation to the mean lunation. Rejected because it is much easier to use SOLEX for numerical integration, SOLEX is able to go much farther into the past or future than the JPL routines, and SOLEX will be able to carry out automatic binary searches for the actual moments of the northward equinox and lunar conjunction (see #26).
19.	Done	In the MoladMoment function, calculate parts as integers separately from days, to avoid the floating point limitations of storing both together as a double-precision moment, and allow a fractional day offset to be passed as a parameter for convenient use during processing of Rosh HaShanah postponement rules (plus quarter day), conversion to civil time (minus quarter day), or conversion to Universal Time (minus 8h 21m). The traditional molad moment always has a an integer number of parts representing the fraction of a day, so the progressive molad should be correspondingly rounded to the nearest part.
20.	Done	Because of the Gauss "plus quarter day" shortcut, together with my strategy of checking the weekday of the next or prior molad of Tishrei when necessary, the Rosh HaShanah postponement rules don't actually need to know the molad fraction of a day, just the day of the molad, thus further simplifying the HebrewNewYear function.
21.	Rejected	Instead of using a "Delta" coefficient to find-tune the long-term equinox alignment, use a one-time epoch offset. This will simplify the calendar arithmetic by eliminating the Delta coefficient from the leap rule and elapsed months expressions, and there will be a direct relationship between the epoch offset and the long-term equinox alignment. This would also prevent the list of leap years from changing for alternate choices of long-term equinox alignments. Rejected because calendar months are constrained to start in a fixed relationship relative to the molad. Thus it is impossible to shift the epoch by small increments. The only way to do what was suggested would be to shift the epoch by entire years to obtain the desired equinox alignment. This could be done by using a different year number for the purposes of calendar arithmetic, or by actually changing the traditional year numbering. Neither of these alternatives seems acceptable.
22.	Done	Rename rectified molad to progressive molad, because it parallels the progressively shorter mean lunation interval. This document was included, so the old term does not otherwise appear even in older suggestions above.
23.	Rejected	Pick two total eclipses from a long Saros series, both near perihelion, so that their conditions will be as similar as possible. Rejected because the work completed in #24 made further eclipse-based studies unnecessary.
24.	Evaluation Complete	Before carrying out the quadratic least-squares regression, reduce and smooth the lunation duration data using a technique such as iterative trinary reductive scattergram smoothing to 4th, 5th or 6th order (as necessary to produce the optimal smoothing). This will reduce the influence of the most exceptional lunation lengths and dramatically accelerate the statistical curve fitting. Reductive smoothing will cause the smoothed data to start after the initially selected eclipse and to end before the final selected eclipse, so the particular eclipses that are chosen may become unimportant. This technique seems to work well, and will probably be the method of choice for reducing the SOLEX data (see #26).
25.	Done	Separate the progressive molad arithmetic from the Delta T correction by making a progressive molad function that works in terms of atomic time, converted to mean solar time by subtracting the corresponding Delta T. This strategy avoids unpredictable errors due to future variations in the Earth rotation rate. This has been implemented as an internal function in Kalendis using the name RAPmolad (RAP being an acronym for Rotation-Adjusted Progressive), but I deferred its adoption until it can be based on SOLEX data (see #26).
26.	Done, but not published because decided to go with #27 and #28 below instead.	Use SOLEX numerical integration to find the accurate moments of equinoxes, solstices, and lunar conjunctions, then use that data as a "gold standard" for reevaluating and refining the calendar and molad arithmetic. The lunar phase of this work is complete, resulting in accurate functions for the Mean New Moon moment at the Prime Meridian, in terms of Terrestrial Time (TT, atomic time) or Universal Time (UT, mean solar time), see my new web page "The Length of the Lunar Cycle" at <http://individual.utoronto.ca/kalendis/lunar/>. The new Progressive Molad will simply be the UT mean new moon plus 2h 21m to switch it to a Jersualem Mean Solar Time clock, plus, as is traditional, 6 hours to count time from mean sunset instead of civil midnight. The improved arithmetic now takes into account the long-term variations in the length of the lunar cycle that are caused by long-term periodic variations in the Earth axial tilt (obliquity).
27.	Planning	It may not be appropriate to shift the molad reference meridian to Jerusalem! See the new alternative interpretation of its position on "The Molad of the Hebrew Calendar" web page. Instead, it could be left at its original historical position, following the policy of restoration of the calendar to the original state that it had relative to the astronomy in the era of Hillel ben Yehudah. Simple arithmetic can be provided to express the moment in terms of any time zone, such as Israel Time, but the calendar itself will go by the mean solar time at its original reference meridian = halfway between the Nile and the end of the Euphrates river, or about 4° east of Jerusalem.
28.	Planning	Like #27 above, the reference meridian for the northward equinox should also be calculated for 4° east of Jerusalem instead of Jerusalem mean solar time.