# Proposal For Hebrew Calendar Reform

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
We've had several proposals on this forum for new solar calendars. But so far, nobody has done a lunisolar calendar (although Wendy has sort of done so with a new algorithm for Easter). So, I'll take up the challenge, by finding a way to make the Hebrew Calendar a little more accurate.

The existing calendar is based on three cycles:

The Week

Is 7 days long, ending with Shabbat. This won't change, so there's nothing to discuss.

The Month

Each month begins with a new moon. Originally, this was based on observation, but today, it's based on a calculated synodic month of 29 days, 12 hours, and 793 halakim (1080ths of an hour), which is exactly 765433/25920 days. That's 29.53059413580247 in decimal (25;644X49724972.... dozenal).

For comparison, the astronomical synodic month (based on USNO data) is 29.5305873949 days (25;644X3157B283). So, a Hebrew month is 582 ms (3;43 Tm) too long. That's impressive accuracy, but still, it adds up to an hour every 500 years or so.

The Year

The Hebrew year is based on a strict Metonic cycle of 19 years = 235 months (that is, an intercalary month [Adar I] is added 7 times every 19 years). The average length of a year is therefore 235/19 * 765433/25920 = 35975351/98496 = 365.24682220597794. That's 6.4 minutes longer than an astronomical equinoctial year. The error adds up to a day every 219 years. This is an improvement over the Julian calendar, with 1 day of error every 131 years, but large enough to be problematic.

The Combined Cycle

The calendar repeats itself every 689 472 years. This figure is exactly equal to 8 527 680 months, 35 975 351 weeks, or 251 827 457 days.

The first step in developing the new calendar is to establish new values for these cycles.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
How long should a month be?

The two criteria I shall use to determine the mean length of a calendar month are:
• The value should be at least as accurate as the status quo. This means between 29.53058065399753 and 29.53059413580247 days.
• The denominator shall be reasonably small. This means no greater than *1000.
The candidates for the fractional part of the number of days in a month are thus:
• 347/654
• 373/703
• 399/752
• 425/801
• 451/850
• 477/899
• 503/948
• 529/997
• 555/1046
• 581/1095
• 720/1357
• 772/1455
• 824/1553
• 876/1651

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Note, however, that the length of a day is gradually getting longer, and this causes the number of days in a lunar month to decrease. Dr. Irv Bromberg's Rectified Hebrew calendar deals with this phenomenon by making each successive month about 27 Âµs (3;4 4Tm) shorter than the last.

I, however, will ignore it, except to give myself more flexibility in determining the length of the molad interval.

As I calculated in another thread based on USNO data, the approximate time of the new moon is the Julian date

-2.0051826865596922e-10 * x2 + 29.530586740228046 * x + 2451550.0952949869

where x is the number of months that have elapsed since Y2K. Taking the derivative gives the length of a month as:

29.530586740228046 - 4.0103653731193845e-10 * x

The rate of decrease works out to 34.65 Âµs per month, slightly higher than calculated by Bromberg.

Because the length of a month is decreasing, and the current approximation is slightly too long anyway, then the requirement of "a better approximation than the status quo" gives a wider interval of allowed approximations in the future.

For my reference point, I will choose Rosh Hashana of the Jewish year 6000 (using the existing calendar). This corresponds to the gregorian date 2239-09-30, and is 2965 synodic months (239.72 Metonic years) after Y2K. By the formula above, the length of a month then will be 29.53058555115471 days.

The length of the approximated month, then, should be between 29.530576966506953 and 29.53059413580247 days. And the valid (with denominators no more than *1000) fractional approximations for the non-integer part of the number are:
• 321/605
• 347/654
• 373/703
• 399/752
• 425/801
• 451/850
• 477/899
• 503/948
• 529/997
• 555/1046
• 581/1095
• 616/1161
• 668/1259
• 720/1357
• 772/1455
• 824/1553
• 876/1651

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
An alternative way to ask the question is: How many weeks should be in the mean calendar month? This might not necessarily have a one-to-one correspondence with the previous list, due to the arbitrary limit on denominators.

Using the same calculations as the previous post, the approximated month should be between 4.218653852358136 and 4.218656305114639 weeks. Fractions that fall into this range are:
• 143/654
• 218/997
• 361/1651
Converting to day fractions by adding 4, multiplying by 7, and subtracting 29, gives:
• 347/654
• 529/997
• 876/1651
Which is a strict subset of the previous set. It doesn't give us any additional options.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The other natural cycle that needs to be approximated is the solar year.

A year can be defined by the time between two equinoxes, or two solstices, or an average thereof. For the Hebrew calendar, the event that matters is the March equinox. This is because the intercalary month is explicitly intended to ensure that Pesach (Passover) doesn't occur too early.

Based on the formula I derived in the Calendar Calculations thread from this table, the length of an vernal equinoctial year is 365.24236968356126 - 5.7533554809197085e-08 * x, where x is the number of years since the March 20, 2000 equinox.

The Gregorian calendar (which I shall use as a minimum standard of accuracy) approximates the year as 365.2425 days.

Again, we have an existing approximation that's too long, for a natural cycle that's decreasing in length, so in the future, the range of valid approximations will be wider.

Using the vernal equinox of the Jewish year 5999 (Gregorian 2239) as the reference point, the extrapolated astronomical length of a year will be 365.24235593304167 days. In order to meet the requirement of being more accurate than the Gregorian calendar, the approximated year will need to be between 365.2422118660833 and 365.2425 days.

Let's also require the denominator to be less than the Gregorian calendar's 400. That gives us the following choices for the non-integer part of the number:
• 8/33
• 39/161
• 47/194
• 55/227
• 63/260
• 70/289
• 71/293
• 79/326
• 86/355
• 87/359
• 95/392
If the calculation is done in terms of weeks instead, the valid remainders are 8/33, 71/293, and 86/355.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The posts above give 17 possible approximations for the synodic month, and 11 possible approximations for the equinoctial year. When these are treated as [i]independent[/i] cycles, that gives 187 possible combinations. To choose between them, I shall pick the one [b]whose full repeating cycle[/b] (least common multiple of year, month, and week) [b]is the shortest[/b]. Unsurprisingly, the shortest repeating cycle has the simplest synodic month approximation. Surprisingly, it does [i]not[/i] have the simplest (8/33) year approximation, but a 260-year cycle instead.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
To make sure I didn't miss any better choices by arbitrarily limiting the denominators, I just wrote a computer program to help calculate:

Code: Select all

import sys
from fractions import Fraction
from functools import reduce
from math import ceil, floor

MIN_MONTH = 29.530576966506953
MAX_MONTH = 29.53059413580247

MIN_YEAR = 365.2422118660833
MAX_YEAR = 365.2425

INFINITY = float&#40;'inf'&#41;

def _gcd2&#40;a, b&#41;&#58;
&nbsp; &nbsp;"""
&nbsp; &nbsp;Return a greatest common divisor of two numbers
&nbsp; &nbsp;"""
&nbsp; &nbsp;a = abs&#40;a&#41;
&nbsp; &nbsp;b = abs&#40;b&#41;
&nbsp; &nbsp;while b&#58;
&nbsp; &nbsp; &nbsp; &nbsp;a, b = b, a % b
&nbsp; &nbsp;return a

def gcd&#40;*args&#41;&#58;
&nbsp; &nbsp;"""
&nbsp; &nbsp;Return the greatest common divisor of two or more numbers.
&nbsp; &nbsp;"""
&nbsp; &nbsp;return reduce&#40;_gcd2, args&#41;

def repeat_cycle&#40;month_approx, year_approx&#41;&#58;
&nbsp; &nbsp;"""
&nbsp; &nbsp;Given values for the approximated synodic month and solar year &#40;in days&#41;,
&nbsp; &nbsp;return # of &#40;years, months, weeks, days&#41; in shortest repeating cycle.
&nbsp; &nbsp;"""
&nbsp; &nbsp;result = &#91;1 / year_approx, 1 / month_approx, Fraction&#40;1, 7&#41;, Fraction&#40;1&#41;&#93;
&nbsp; &nbsp;multiplier = result&#91;0&#93;.denominator * result&#91;1&#93;.denominator * 7
&nbsp; &nbsp;result = &#91;int&#40;value * multiplier&#41; for value in result&#93;
&nbsp; &nbsp;divisor = gcd&#40;*result&#41;
&nbsp; &nbsp;return tuple&#40;value // divisor for value in result&#41;

def shortest_cycle&#40;max_month_denom, max_year_denom&#41;&#58;
&nbsp; &nbsp;"""
&nbsp; &nbsp;Find the combination&#40;s&#41; of month and year approximations that
&nbsp; &nbsp;minimizes the repeating cycle.

&nbsp; &nbsp;Returns a set of results, consisting of tuples&#58;
&nbsp; &nbsp;&#40;days/month, days/year, years/cycle, months/cycle, weeks/cycle, days/cycle&#41;
&nbsp; &nbsp;"""
&nbsp; &nbsp;min_cycle_days = INFINITY
&nbsp; &nbsp;result = {}
&nbsp; &nbsp;# Precompute lists of possible approximations of month and year
&nbsp; &nbsp;month_candidates = &#91;Fraction&#40;n, d&#41; for d in range&#40;1, max_month_denom + 1&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for n in range&#40;int&#40;ceil&#40;d * MIN_MONTH&#41;&#41;, int&#40;floor&#40;d * MAX_MONTH&#41;&#41; + 1&#41;&#93;
&nbsp; &nbsp;year_candidates = &#91;Fraction&#40;n, d&#41; for d in range&#40;1, max_year_denom + 1&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for n in range&#40;int&#40;ceil&#40;d * MIN_YEAR&#41;&#41;, int&#40;floor&#40;d * MAX_YEAR&#41;&#41; + 1&#41;&#93;
&nbsp; &nbsp;# For debugging
&nbsp; &nbsp;print&#40;'%d candidates for month length' % len&#40;month_candidates&#41;&#41;
&nbsp; &nbsp;print&#40;'%d candidates for year length' % len&#40;year_candidates&#41;&#41;
&nbsp; &nbsp;# Brute-force calculation of the shortest cycle
&nbsp; &nbsp;for year_approx in year_candidates&#58;
&nbsp; &nbsp; &nbsp; &nbsp;for month_approx in month_candidates&#58;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cycle = repeat_cycle&#40;month_approx, year_approx&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cycle_days = cycle&#91;-1&#93;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if cycle_days < min_cycle_days&#58;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;min_cycle_days = cycle_days
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;result = {&#40;month_approx, year_approx&#41; + cycle}
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;elif cycle_days == min_cycle_days&#58;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;result.add&#40;&#40;month_approx, year_approx&#41; + cycle&#41;
&nbsp; &nbsp;return result

def _main&#40;argv=None&#41;&#58;
&nbsp; &nbsp;if argv is None&#58;
&nbsp; &nbsp; &nbsp; argv = sys.argv
&nbsp; &nbsp;if len&#40;argv&#41; < 3&#58;
&nbsp; &nbsp; &nbsp; print&#40;"Usage&#58; python newhebcal.py MAX_MONTH_DENOM MAX_YEAR_DENOM", file=sys.stderr&#41;
&nbsp; &nbsp;else&#58;
&nbsp; &nbsp; &nbsp; for &#40;month_approx, year_approx, cycle_years, cycle_months, cycle_weeks, cycle_days&#41; in shortest_cycle&#40;int&#40;argv&#91;1&#93;&#41;, int&#40;argv&#91;2&#93;&#41;&#41;&#58;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print&#40;&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print&#40;'Month = %d+%s days' % divmod&#40;month_approx, 1&#41;&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print&#40;'Year = %d+%s days' % divmod&#40;year_approx, 1&#41;&#41;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; print&#40;'Cycle = %d yr = %d mo = %d wk = %d d' % &#40;cycle_years, cycle_months, cycle_weeks, cycle_days&#41;&#41;

if __name__ == '__main__'&#58;
&nbsp; &nbsp;_main&#40;&#41;
Running the command with the arguments 1728 and 399 gives the same result as calculated earlier:

Code: Select all

23 candidates for month length
24 candidates for year length

Month = 29+347/654 days
Year = 365+63/260 days
Cycle = 56420 yr = 697818 mo = 2943853 wk = 20606971 d
By allowing denominators up to *1000 for both, I get a shorter cycle:

Code: Select all

23 candidates for month length
433 candidates for year length

Month = 29+503/948 days
Year = 365+327/1349 days
Cycle = 47215 yr = 583968 mo = 2463560 wk = 17244920 d

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Increasing the limit to *10000 reveals an even shorter cycle:

Code: Select all

3689 candidates for month length
61973 candidates for year length

Month = 29+2958/5575 days
Year = 365+437/1803 days
Cycle = 1803 yr = 22300 mo = 94076 wk = 658532 d
The same cycle has been suggested by Dr. Irv Bromberg.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The 1803-year cycle seems to be the best one possible with the YEAR_MIN and MONTH_MIN values listed above. Let's see if we can improve this by increasing the error tolerance just a tad.

In the program above, the range of acceptable values for a month has a range of about 0.445 helek. Let's expand this to half a helek by reducing MONTH_MIN to 29.530574845679013. This is equivalent to assuming that the current Hebrew calendar approximation is correctly rounded, but rounded up. By applying the same idea to the Gregorian approximation of the year, the YEAR_MIN should be 365.24125. (Otherwise, it would be more accurate without the 400-year leap year exception.)

The best result I can get from my program is

Code: Select all

Month = 29+555/1046 days
Year = 365+143/592 days
Cycle = 592 yr = 7322 mo = 30889 wk = 216223 d
The approximation of the synodic month is just 121 ms less than the value used by the existing Hebrew calendar.

The approximation of the year is about 70 seconds too short, so will accumulate 1 day of error every 1230 years (until the earth slows down to match). This is 6 times as accurate as the existing calendar, and 9 times as accurate as the Julian calendar. It is, however, less accurate than the Gregorian calendar.

Despite this, it's probably "good enough", so it's the cycle I'll use for the rest of the calculations.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The intervals between molads and equinoxes having been established, the next question to answer is when they are.

Returning to the quadratic approximations of these events:

MoladJD = -2.0051826865596922e-10 * x2 + 29.530586740228046 * x + 2451550.0952949869
where x = number of synodic months since 2000-01-06

EquinoxJD = -2.8766777404598542e-08 * x2 + 365.24236968356126 * x + 2451623.8110382501
where x = number of years since 2000-03-02

Now, pick arbitrary x's on which to base the calendar. Choosing two examples at random:

May 15, 1948
• For monthly cycle, x = -639, so calculated molad date is 2432680.0502861054 (1948-05-08 13:12:24)
• For annual cycle, x = -52, so calculated equinox date is 2432631.2077369196 (1948-03-20 16:59:08)
By adding 639 approximated months (of 29.53059273422562 days) and 52 approximated years (of 365.24155405405406 days), we arrive at the Y2K values:
• Molad = 2451550.0990432757 (2000-01-06 14:22:37)
• Equinox = 2451623.7685477305 (2000-03-20 06:26:42)
June 7, 1967
• For monthly cycle, x = -404, so calculated molad date is 2439619.738219207 (1967-05-09 05:43:02)
• For annual cycle, x = -33, so calculated equinox date is 2439570.812807366 (1967-03-21 07:30:26)
Adding 404 months and 33 years to get the corresponding Y2K-based values:
• Molad = 2451550.0976838344 (2000-01-06 14:20:39)
• Equinox = 2451623.7840911495 (2000-03-20 06:49:05)

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
So far, all calculations have been done with Julian dates (with the day starting at 12:00) at the UTC timezone. It would be more convenient for Hebrew calendar calculations to have the day start at sunset (or 18:00) Jerusalem mean time. The longitude of the Temple Mount is 35.2354Â° E, which works out to a UTC offset of +2:20:56.5. So, 18:00 Jerusalem mean time is equivalent to 15:39:03.5 UTC.

Define the Jerusalem Julian Date (JJD) as the Julian Date minus 0.1521238425925926. This adjusts for the 3:39:03.5 difference between 12:00 UTC and 18:00 JMT.

Using the 1967 reference point from the previous post, the dates of the first molad and vernal equinox after Y2K are:
• Molad = JJD 2451549.945559992
• Equinox = JJD 2451623.631967307
For the sake of avoiding floating-point arithmetic, let's introduce a new unit of time, which I shall uncreatively call a "tick". There are exactly 928 848 ticks per day, or 38 702 ticks per hour. This value allows the monthly and annual cycles to be expressed in terms of whole ticks:
• 1 month = 29 days, 12 hours, 28416 ticks
• 1 year = 365 days, 5 hours, 30857 ticks
The Y2K molad and equinox times expressed in terms of ticks are:
• Molad = JJD 2451549 + 878282 ticks
• Equinox = JJD 2451623 + 587001 ticks

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The next question to ask is "On what date does the year begin?" Assuming we preserve the existing calendar structure with ten of the months having fixed lengths, a simplistic answer is "The year begins exactly 163 days after the first night of Pesach." Of course, that raises the obvious question of when Pesach is.

This year (2013/5773), Pesach started on March 26. This happens to currently be the earliest possible date. Moreover, it was the second-to-last time that Pesach will ever start on March 26; the next time this will happen will be in 2089/5849, after which calendar drift will push it to the 27th and later.

In the past, Pesach could start on earlier dates:
• The last time it fell on March 25 was in 1766/5526.
• The last time it fell on March 24 was in 1652/5412.
• The last time it fell on March 23 was in 1348/5108.
• The last time it fell on March 22 was in 987/4747.
• The last time it fell on March 21 was in 873/4633.
• The last time it fell on March 20 was in 664/4424.
• The last time it fell on March 19 was in 493/4253.
• The last time it fell on March 18 was in 132/3892.
If the current calendar rules were indeed designed by Hillel II, then March 19 would be the earliest Gregorian date on which Pesach ever started since their adoption. This could be a day before the vernal equinox. But for the sake of simplicity, I shall assume that Pesach must start after the vernal equinox.

The Molad of Tishri can then be calculated as follows:
1. Compute the date/time of the preceding vernal equinox.
2. Add 163 days.
3. Find the date/time of the next new moon. That is the molad of Tishri.
4. If the molad falls before noon, then (the unadjusted date of) Rosh Hashana starts the following evening. Otherwise, delay it by a day.
The adjustments will be covered later.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
The Molad of Tishri may occur on any day of the week. However, for reasons of Jewish law that are outside the scope of this thread, it's inconvenient for Rosh Hashana to fall on a Sunday, Wednesday, or Friday. So, if this would happen, we delay it by a day.

The calculation of the reformed Rosh Hashana data, expressed in Python code, is:

Code: Select all

from datetime import date
from fractions import Fraction

MONTH_LENGTH &nbsp; &nbsp;= 29 + Fraction&#40;555, 1046&#41;
YEAR_LENGTH &nbsp; &nbsp; = 365 + Fraction&#40;143, 592&#41;
Y2K_MOLAD_JJD &nbsp; = 2451549 + Fraction&#40;878282, 928848&#41;
Y2K_EQUINOX_JJD = 2451623 + Fraction&#40;587001, 928848&#41;

def floor&#40;frac&#41;&#58;
&nbsp; &nbsp;return frac.numerator // frac.denominator

def ceil&#40;frac&#41;&#58;
&nbsp; &nbsp;return -floor&#40;-frac&#41;

def rosh_hashana&#40;year&#41;&#58;
&nbsp; &nbsp;equinox_jjd = Y2K_EQUINOX_JJD + &#40;year - 5761&#41; * YEAR_LENGTH
&nbsp; &nbsp;# Molad of Tishrei = first new moon at least 163 days after equinox
&nbsp; &nbsp;lunation_number = ceil&#40;&#40;equinox_jjd + 163 - Y2K_MOLAD_JJD&#41; / MONTH_LENGTH&#41;
&nbsp; &nbsp;molad_jjd = Y2K_MOLAD_JJD + lunation_number * MONTH_LENGTH
&nbsp; &nbsp;# Rosh Hashana starts at JJD x.0 after the molad.
&nbsp; &nbsp;# Dehiyyah Molad Zaken&#58; If molad time >= noon, postpone RH by a day.
&nbsp; &nbsp;rh_jjd = floor&#40;molad_jjd + Fraction&#40;1, 4&#41;&#41;
&nbsp; &nbsp;rh = date.fromordinal&#40;int&#40;rh_jjd&#41; - 1721424&#41;
&nbsp; &nbsp;# Dehiyyah Lo ADU
&nbsp; &nbsp;# If RH would be on Sun, Wed, or Fri, postpone it
&nbsp; &nbsp;if rh.weekday&#40;&#41; in &#40;6, 2, 4&#41;&#58;
&nbsp; &nbsp; &nbsp; &nbsp;rh += timedelta&#40;days=1&#41;
&nbsp; &nbsp;return rh
However, for technical reasons, some more adjustments may still be required...

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
In the current Hebrew calendar, there are 3 intercalation points:
• The leap month of Adar I, having 30 days, may be added between Shevat and Adar (II).
• The month of Cheshvan may have either 29 or 30 days.
• The month of Kislev may have either 29 or 30 days.
The remaining ten months have a fixed length of 295 days. Therefore, there are 6 possible lengths of a year:
• 353 days
• 354 days
• 355 days
• 383 days
• 384 days
• 385 days
Using the calculation in my previous post, the frequency count of calendar year lengths over the full 592-year cycle are:
• 353: 67
• 354: 122
• 355: 166
• 356: 19
• 382: 2
• 383: 101
• 384: 32
• 385: 83
As in the existing Hebrew calendar, the illegal year lengths will be "fixed" by adding more postponement rules. First, let's address the 356-day years. These occur when the year (anno mundi) modulo 592 falls in the set {45, 65, 72, 92, 143, 163, 170, 241, 312, 319, 339, 390, 410, 417, 437, 488, 515, 559, 586}, and start on a Tuesday.

We can shorten the year to a valid length of 355, 354, or 353 days by postponing Rosh Hashana to Wednesday, Thursday, or Friday, respectively. Since Rosh Hashana cannot occur on Wednesday or Friday, the only choice is Thursday. So, Rosh Hashana will be postponed by 2 days.

After making this change, the distribution of year lengths becomes:
• 353: 59
• 354: 141
• 355: 174
• 382: 2
• 383: 90
• 384: 32
• 385: 94
The 382-day years occur when the anno mundi year, modulo 592, is 210 or 457. These years start Thurdays. We could increase their length to a legal 384 days by making Rosh Hashana 2 days earlier, but months aren't supposed to start before the molad.

Instead, we will postpone the start of the following years, i.e., 211 and 458 of the 592-year cycle. These years would otherwise start on Monday and be 355 days long. Postponing Rosh Hashana to Tuesday (which is valid) makes them 354 days long (which is also valid).

The final Rosh Hashana computation with all the postponement rules in place is:

Code: Select all

from datetime import date
from fractions import Fraction

MONTH_LENGTH &nbsp; &nbsp;= 29 + Fraction&#40;555, 1046&#41;
YEAR_LENGTH &nbsp; &nbsp; = 365 + Fraction&#40;143, 592&#41;
Y2K_MOLAD_JJD &nbsp; = 2451549 + Fraction&#40;878282, 928848&#41;
Y2K_EQUINOX_JJD = 2451623 + Fraction&#40;587001, 928848&#41;

def floor&#40;frac&#41;&#58;
&nbsp; &nbsp;return frac.numerator // frac.denominator

def ceil&#40;frac&#41;&#58;
&nbsp; &nbsp;return -floor&#40;-frac&#41;

def rosh_hashana&#40;year&#41;&#58;
&nbsp; &nbsp;equinox_jjd = Y2K_EQUINOX_JJD + &#40;year - 5761&#41; * YEAR_LENGTH
&nbsp; &nbsp;# Molad of Tishrei = first new moon at least 163 days after equinox
&nbsp; &nbsp;lunation_number = ceil&#40;&#40;equinox_jjd + 163 - Y2K_MOLAD_JJD&#41; / MONTH_LENGTH&#41;
&nbsp; &nbsp;molad_jjd = Y2K_MOLAD_JJD + lunation_number * MONTH_LENGTH
&nbsp; &nbsp;# Rosh Hashana starts at JJD x.0 after the molad.
&nbsp; &nbsp;# Dehiyyah Molad Zaken&#58; If molad time >= noon, postpone RH by a day.
&nbsp; &nbsp;rh_jjd = floor&#40;molad_jjd + Fraction&#40;1, 4&#41;&#41;
&nbsp; &nbsp;rh = date.fromordinal&#40;int&#40;rh_jjd&#41; - 1721424&#41;
&nbsp; &nbsp;# Dehiyyah Lo ADU
&nbsp; &nbsp;# If RH would be on Sun, Wed, or Fri, postpone it
&nbsp; &nbsp;if rh.weekday&#40;&#41; in &#40;6, 2, 4&#41;&#58;
&nbsp; &nbsp; &nbsp; &nbsp;rh += timedelta&#40;days=1&#41;
&nbsp; &nbsp;# Dehiyyah GaTaRaD
&nbsp; &nbsp;# Shorten 356-day years to 354 days
&nbsp; &nbsp;if year % 592 in &#40;45, 65, 72, 92, 143, 163, 170, 241, 312, 319, 339, 390,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;410, 417, 437, 488, 515, 559, 586&#41;&#58;
&nbsp; &nbsp; &nbsp; &nbsp;rh += timedelta&#40;days=2&#41;
&nbsp; &nbsp;# Dehiyyah BeTUTeKaPoT
&nbsp; &nbsp;# Eliminate 382-day years by shorting the subsequent years
&nbsp; &nbsp;if year % 592 in &#40;211, 458&#41;&#58;
&nbsp; &nbsp; &nbsp; &nbsp;rh += timedelta&#40;days=1&#41;
&nbsp; &nbsp;return rh
and the frequency count of year lengths is:
• 353: 59
• 354: 143
• 355: 172
• 383: 92
• 384: 32
• 385: 94

Obsessive poster
Kodegadulo
Obsessive poster
Joined: Sep 10 2011, 11:27 PM
Wow talk about complexity! And I thought the Gregorian calendar was a nightmare...
As of 1202/03/01[z]=2018/03/01[d] I use:
ten,eleven = ↊↋, ᘔƐ, ӾƐ, XE or AB.
Base-neutral base annotations
Systematic Dozenal Nomenclature
Primel Metrology
Western encoding (not by choice)
Greasemonkey + Mathjax + PrimelDozenator
(Links to these and other useful topics are in my index post;
click on my user name and go to my "Website" link)

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Kodegadulo @ Apr 14 2013, 12:53 PM wrote: Wow talk about complexity! And I thought the Gregorian calendar was a nightmare...
The Gregorian Calendar is simple because it's a purely solar calendar and doesn't have to track the phases of the moon. Also, its month/year structure is completely independent of the week; i.e., it doesn't have rules to prevent holidays from falling on inconvenient days.

OTOH, if you include the computation of Easter, the Gregorian Calendar is arguably more complex than the Hebrew one.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Most of the time, the "new" Rosh Hashana date coincides with the "old" date. The years between Gregorian 2000 and 2100 (inclusive) when it doesn't are: Most of the differences are 1 month. These occur in years 1, 4, 9, and 12 of the Metonic cycle (Y mod 19) when Rosh Hashana (and thus, the preceding Pesach) occurs "late" under the current calendar. Note that the year 2095/5856 will be the first time that a one-month difference between the two calendars will affect year 4 in the Metonic cycle. For now, only 3 years in the 19-year cycle start "late": [list] [*]Y mod 19 = 9, since 1207/4968 [*]Y mod 19 = 1, since 1503/5264 [*]Y mod 19 = 12, since 1799/5560 [/list] There are also 1-day and 2-day differences. The ones adjacent to the leap year changes are due to the postponement rules.

Dozens Demigod
dgoodmaniii
Dozens Demigod
Joined: May 21 2009, 01:45 PM
Dan @ Apr 14 2013, 07:22 PM wrote: OTOH, if you include the computation of Easter, the Gregorian Calendar is arguably more complex than the Hebrew one.
I think that's right; the Gregorian calendar is a simpler way to keep the seasons at the same time of year. It's equally complex as the Hebrew calendar, at least, when we add in religious holidays, presidential birthdays, and the like.
All numbers in my posts are dozenal unless stated otherwise.
For ten, I use or X; for elv, I use or E. For the digital/fractional/radix point, I use the Humphrey point, ";".
TGM for the win!
Dozenal Adventures

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
dgoodmaniii @ Apr 14 2013, 03:40 PM wrote:I think that's right; the Gregorian calendar is a simpler way to keep the seasons at the same time of year.
It doesn't do an ideal job of that, though. Assuming that the 365.2425-day average year length is correct, the standard deviation of the equinox date/time is 10 h 41 min 28 s. If, however, the 97 leap days in each 400-year cycle were distributed as evenly as possible, then the standard deviation would be only 6 h 55 min 41 s (almost the same as a continuous uniform distribution with a range of 1 day).

However, it's simple in the sense that it's easy to distinguish leap years from common years â€” if you use base-ten. (In dozenal, the 4-year rule is simplified, but the 100-year and 400-year rules become a more awkward 84 and 294.)
dgoodmaniii @ Apr 14 2013, 03:40 PM wrote:It's equally complex as the Hebrew calendar, at least, when we add in religious holidays, presidential birthdays, and the like.
I work in the private sector, so have to work on presidential birthdays. But you've got a point. (For example, with our "floating company-declared holiday" in December.)

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
It's possible to simplify the calculation of the Rosh Hashana date.

For example, instead of explicitly calculating the equinox:

Code: Select all

 &nbsp; equinox_jjd = Y2K_EQUINOX_JJD + &#40;year - 5761&#41; * YEAR_LENGTH
&nbsp; # Molad of Tishrei = first new moon at least 163 days after equinox
&nbsp; lunation_number = ceil&#40;&#40;equinox_jjd + 163 - Y2K_MOLAD_JJD&#41; / MONTH_LENGTH&#41;
the lunation number can be calculated directly using the formula:

Code: Select all

lunation_number = year * 12 + &#40;109 * year + 167&#41; // 296 - 71245
• year * 12 is the number of elapses months if there were no intercalation.
• The expression (109 * year + 167) // 296 is the adjustment for leap years:
• 109/296 is the proportion of years that are 13-month leap years (218 leap years every 592-year cycle; slightly less than the 7/19 of the existing calendar).
• 167 is an adjustment to make the leap years fall in the right place. I don't know how to derive it; I obtained it by brute force.
• 71245 is the number of synodic months in 5760.3 years, and adjusts for the difference between the Meeus lunation epoch and the Hebrew calendar epoch.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
As stated earlier, the average length of a year in the 592-year cycle is 365+143/592 = 365.24155405405406 days. This is 81.729729... seconds shorter than the mean Gregorian year of 365.2425 days, and 70.4 seconds less than the true equinoctial year (365.242368931396 days) derived from the astronomical data posted earlier.

This means that the calendar drifts one day earlier every 1227 years. This is an improvement over the existing Metonic calendar (365.24682220597794 days), which drifts one day later every 225 years. However, that the drift is backwards means that eventually, Pesach will occur before the equinox.

The drift can be lessened by using a longer cycle. The shortest cycle that gives a (slightly) more accurate mean length of the year is 1556 yr = 19245 mo = 81188 wk = 568316 d, for a year of 365.24164524421593 days. A calendar based on this cycle would drive one day earlier every 1382 years. This is a marginal improvement over the 592-year cycle, and may not be worth bothering with.

A large accuracy improvement can be obtained by using the cycle 1803 yr = 22300 mo = 94076 wk = 658532 d. As shown earlier, this is the shortest cycle which has both a more accurate approximation of the synodic month than the existing Hebrew calendar, and a more accurate approximation of the equinoctial year than the Gregorian calendar. The approximated year is 365.24237382140876 days, a mere 422 ms longer than the current equinoctial year, and exactly matched it in 1928. The approximated month is 29.530582959641254 days, only 320 ms less than the current true value of 29.53058667437678 days (derived from the USNO data), which will become exact in 2762.

 Posts 773
Dozens Disciple
Oschkar
Dozens Disciple
Joined: Nov 19 2011, 01:07 AM
How bad, comparatively, would a slightly shorter cycle of 1040 years = 12863 months = 379852 days be? Assuming it was perfectly in sync on the June solstice of 9564 BC, how far would it have drifted by now?

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Oschkar @ Jun 3 2017, 02:45 AM wrote: How bad, comparatively, would a slightly shorter cycle of 1040 years = 12863 months = 379852 days be? Assuming it was perfectly in sync on the June solstice of 9564 BC, how far would it have drifted by now?
Well, let's see. On such a calendar,
• The average year length is 365.2423076923077 days, which is accurate (to the equinoctial year) to 1 day in 15 000 years.
• The average month length is 29.530591619373396 days, which is accurate to 1 day in 29 000 years.
This is very good accuracy. But a 379852-cycle has the disadvantage of not being a whole number of 7-day weeks. When this is considered, your proposal has a cycle of 7280 years.

Dozens Disciple
Dan
Dozens Disciple
Joined: Aug 8 2005, 02:45 PM
Since the 592-year cycle has the flaw of making Passover slowly drift earlier, I'll re-do the calculations with the 1803-year cycle. Recall that the average year length is 365+437/1803 days and the average month length is 29+2958/5575 days.

To simplify the math, I will divide the day into 80 413 800 "ticks" — the lowest common multiple of 24 (hours in a day), 1803 (denominator for year length), and 5575 (denominator for month length). One hour is 3 350 575 ticks, and one second is 930.7152777777... ticks, so the tick approximates a millisecond.