zIFBoards - Free Forum Hosting
Enjoy forums? Start your own community for free.

Learn More · Sign-up Now
Welcome to Dozensonline. We hope you enjoy your visit.
You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, and sending personal messages. Registration is simple, fast, and completely free. (You will be asked to confirm your email address before we sign you on.)
Join our community!
If you're already a member please log in to your account to access all of our features:

Name:   Password:


Pages: (2) [1] 2  ( Go to first unread post )

 Proposal For Hebrew Calendar Reform, because Treisaran won't
Dan
Posted: Apr 3 2013, 06:50 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
Dan
Posted: Apr 3 2013, 07:05 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
Top
Dan
Posted: Apr 4 2013, 12:36 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
Top
Dan
Posted: Apr 4 2013, 01:04 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
Dan
Posted: Apr 4 2013, 04:20 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
Dan
Posted: Apr 4 2013, 05:08 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



The posts above give 17 possible approximations for the synodic month, and 11 possible approximations for the equinoctial year. When these are treated as independent cycles, that gives 187 possible combinations.

To choose between them, I shall pick the one whose full repeating cycle (least common multiple of year, month, and week) is the shortest.

  Month    Year              Repeating Cycle           
 (29+x)  (365+x)   Years   Months     Weeks      Days
 347/654  63/260   56420    697818   2943853   20606971
 347/654  70/289  180047   2226870   9394395   65760765
 529/997  71/293  205393   2540356  10716888   75018216
 373/703  71/293  253445   3134677  13224120   92568840
876/1651  71/293  291535   3605784  15211560  106480920
555/1046    8/33  419727   5191298  21900301  153302107
668/1259    8/33  505197   6248417  26359911  184519377
 347/654    8/33  637329   7882662  33254227  232779589
 347/654  71/293  808387   9998352  42179592  295257144
 529/997    8/33  971586  12016841  50694918  354864426
 347/654  86/355  979445  12114042  51104957  357734699


Unsurprisingly, the shortest repeating cycle has the simplest synodic month approximation. Surprisingly, it does not have the simplest (8/33) year approximation, but a 260-year cycle instead.
Top
Dan
Posted: Apr 5 2013, 04:46 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
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('inf')

def _gcd2(a, b):
   """
   Return a greatest common divisor of two numbers
   """
   a = abs(a)
   b = abs(b)
   while b:
       a, b = b, a % b
   return a

def gcd(*args):
   """
   Return the greatest common divisor of two or more numbers.
   """
   return reduce(_gcd2, args)

def repeat_cycle(month_approx, year_approx):
   """
   Given values for the approximated synodic month and solar year (in days),
   return # of (years, months, weeks, days) in shortest repeating cycle.
   """
   result = [1 / year_approx, 1 / month_approx, Fraction(1, 7), Fraction(1)]
   multiplier = result[0].denominator * result[1].denominator * 7
   result = [int(value * multiplier) for value in result]
   divisor = gcd(*result)
   return tuple(value // divisor for value in result)

def shortest_cycle(max_month_denom, max_year_denom):
   """
   Find the combination(s) of month and year approximations that
   minimizes the repeating cycle.

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

def _main(argv=None):
   if argv is None:
      argv = sys.argv
   if len(argv) < 3:
      print("Usage: python newhebcal.py MAX_MONTH_DENOM MAX_YEAR_DENOM", file=sys.stderr)
   else:
      for (month_approx, year_approx, cycle_years, cycle_months, cycle_weeks, cycle_days) in shortest_cycle(int(argv[1]), int(argv[2])):
          print()
          print('Month = %d+%s days' % divmod(month_approx, 1))
          print('Year = %d+%s days' % divmod(year_approx, 1))
          print('Cycle = %d yr = %d mo = %d wk = %d d' % (cycle_years, cycle_months, cycle_weeks, cycle_days))

if __name__ == '__main__':
   _main()


Running the command with the arguments 1728 and 399 gives the same result as calculated earlier:

CODE
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
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
Top
Dan
Posted: Apr 5 2013, 01:01 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



Increasing the limit to *10000 reveals an even shorter cycle:

CODE
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.
Top
Dan
Posted: Apr 6 2013, 01:54 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
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.
Top
Dan
Posted: Apr 7 2013, 03:57 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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)

Top
Dan
Posted: Apr 8 2013, 04:17 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
Top
Dan
Posted: Apr 12 2013, 04:25 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
Dan
Posted: Apr 14 2013, 03:58 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
from datetime import date
from fractions import Fraction

MONTH_LENGTH    = 29 + Fraction(555, 1046)
YEAR_LENGTH     = 365 + Fraction(143, 592)
Y2K_MOLAD_JJD   = 2451549 + Fraction(878282, 928848)
Y2K_EQUINOX_JJD = 2451623 + Fraction(587001, 928848)

def floor(frac):
   return frac.numerator // frac.denominator

def ceil(frac):
   return -floor(-frac)

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


However, for technical reasons, some more adjustments may still be required...
Top
Dan
Posted: Apr 14 2013, 04:58 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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
from datetime import date
from fractions import Fraction

MONTH_LENGTH    = 29 + Fraction(555, 1046)
YEAR_LENGTH     = 365 + Fraction(143, 592)
Y2K_MOLAD_JJD   = 2451549 + Fraction(878282, 928848)
Y2K_EQUINOX_JJD = 2451623 + Fraction(587001, 928848)

def floor(frac):
   return frac.numerator // frac.denominator

def ceil(frac):
   return -floor(-frac)

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


and the frequency count of year lengths is:
  • 353: 59
  • 354: 143
  • 355: 172
  • 383: 92
  • 384: 32
  • 385: 94
Top
Kodegadulo
Posted: Apr 14 2013, 05:53 PM


Obsessive poster


Group: Moderators
Posts: 4,184
Member No.: 606
Joined: 10-September 11



Wow talk about complexity! And I thought the Gregorian calendar was a nightmare...
Top
Dan
Posted: Apr 14 2013, 07:22 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



QUOTE (Kodegadulo @ Apr 14 2013, 12:53 PM)
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.
Top
Dan
Posted: Apr 14 2013, 07:45 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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:

Year Old Date New Date Difference
57612000-09-302000-09-28-2
57662005-10-042005-09-05-29
57692008-09-302008-09-01-29
57772016-10-032016-09-03-30
57852024-10-032024-09-05-28
57882027-10-022027-09-02-30
57892028-09-212028-09-19-2
57902029-09-102029-09-08-2
57962035-10-042035-09-03-31
58042043-10-052043-09-05-30
58062045-09-122045-09-11-1
58072046-10-012046-09-01-30
58152054-10-032054-09-03-30
58232062-10-052062-09-04-31
58262065-10-012065-09-01-30
58342073-10-022073-09-02-30
58422081-10-042081-09-04-30
58452084-09-302084-08-31-30
58532092-10-022092-09-02-30
58562095-09-292095-08-30-30
58612100-10-042100-09-04-30


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":
  • Y mod 19 = 9, since 1207/4968
  • Y mod 19 = 1, since 1503/5264
  • Y mod 19 = 12, since 1799/5560

There are also 1-day and 2-day differences. The ones adjacent to the leap year changes are due to the postponement rules.

Top
dgoodmaniii
Posted: Apr 14 2013, 08:40 PM


Dozens Demigod


Group: Admin
Posts: 1,927
Member No.: 554
Joined: 21-May 09



QUOTE (Dan @ Apr 14 2013, 07:22 PM)
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.
Top
Dan
Posted: Apr 15 2013, 01:21 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



QUOTE (dgoodmaniii @ Apr 14 2013, 03:40 PM)
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.)

QUOTE (dgoodmaniii @ Apr 14 2013, 03:40 PM)
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.)
Top
Dan
Posted: Apr 15 2013, 02:41 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



It's possible to simplify the calculation of the Rosh Hashana date.

For example, instead of explicitly calculating the equinox:

CODE
  equinox_jjd = Y2K_EQUINOX_JJD + (year - 5761) * YEAR_LENGTH
  # Molad of Tishrei = first new moon at least 163 days after equinox
  lunation_number = ceil((equinox_jjd + 163 - Y2K_MOLAD_JJD) / MONTH_LENGTH)


the lunation number can be calculated directly using the formula:

CODE
lunation_number = year * 12 + (109 * year + 167) // 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:
    [LIST]
  • 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.[/LIST]
Top
Dan
Posted: Apr 16 2013, 06:05 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
Oschkar
Posted: Jun 3 2017, 07:45 AM


Dozens Disciple


Group: Members
Posts: 575
Member No.: 623
Joined: 19-November 11



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?
Top
Dan
Posted: Jun 3 2017, 03:16 PM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



QUOTE (Oschkar @ Jun 3 2017, 02:45 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?

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.
Top
Dan
Posted: Jun 5 2017, 06:20 AM


Dozens Disciple


Group: Members
Posts: 1,463
Member No.: 19
Joined: 8-August 05



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.
Top
« Next Oldest | Calendar Reform | Next Newest »
zIFBoards - Free Forum Hosting
Create your own social network with a free forum.
Learn More · Register Now

Topic OptionsPages: (2) [1] 2 



Hosted for free by zIFBoards* (Terms of Use: Updated 2/10/2010) | Powered by Invision Power Board v1.3 Final © 2003 IPS, Inc.
Page creation time: 0.0389 seconds · Archive