Is the TorahCalc Molad Calculator accurate?

I have been making an excel spreadsheet that calculates molads. I started from the Molad for Tishrei in Year 1 Anno Mundi. Based on various websites (including TorahCalc), the Molad was on Tuesday at 23:11 (11:11pm) and 1 cheilek. I used various "if" formulae to continue the series, and begun looking for errors caused by problems in the formulae. After fixing the formulae, I looked again and found something very curious.

You see, the way to calculate the Molad from one month to the next (apparently) is by adding 1 day, 12 hours, 44 minutes, and 1 cheilek. Sounds straigtforward? I thought so.

According to TorahCalc, the Molad for Iyyar (Year 1) was Thursday, 16:19, 8 chalokim. Sivan was Shabbos, 05:03, 9 chalokim. Tammuz was Sunday, 17:47, 10 chalokim. So far so good. But, Av was Tuesday, 06:31, 12 chalokim. They have added two chalokim, instead of 1. Elul was Wednesday, 19:15, 12 chalokim. This time, they haven't added any chalokim (although this would be where they would have ended up had they added only 1 cheilek to the previous month. This seems to be something that you can observe on the TorahCalc Molad Calculator more than just a few times.

My question is as follows: Is the formula of adding 1 day, 12 hours, 44 minutes, and 1 cheilek, a rule that always strictly applies (meaning that TorahCalc is simply wrong) or is there some variation with the chalokim on occasion (meaning that TorahCalc is correct)?

• Perhaps the calculation has to convert to time using seconds which does not come out to the even cheilek. This could cause a round off error that has to be allowed for. Is here a modern date that shows tis difference or is it only the old dates that you use as an example? Commented Jan 24, 2022 at 23:11
• @sabbahillel Year 5000 - Nisan: Shabbos, 18:50, 8 chalokim; Iyyar: Monday, 07:34, 8 chalokim Commented Jan 24, 2022 at 23:14
• 1 day 12 hours 793 chalakim is always true. I know nothing of this program to say if it's you or it that is finding something wrong. Commented Jan 25, 2022 at 1:18
• A cheilek is 3 1/3 seconds. Since this is not an even value, it will cause a roundoff error. 793 chalakim is (793*10)/3 seconds which is 10,746144.444... with infinite repeating to the right of the decimal point. This will cause roundoff errors in the conversion. Commented Jan 25, 2022 at 14:28

In short

It's their algorithm. It appears that they are using an inaccurate constant of 3.3 to back into the number of chalakim from the number of seconds. This constant should instead be 3 + (1/3). Most of the time this is okay, but if the intermediate result aligns just right, an error is introduced that produces the wrong number for the chalakim result.

Details

Since they are using Javascript to calculate the Molad, it should be pretty simple to reverse-engineer their approach.

It seems like the code's starting point is at the year 5776, which it ties to the magic number `144218565e4`. This is the number of milliseconds since 1/1/1970, so some quick math gives us the date Sep 13 2015 19:07:30. In other words, the Molad for Tishrei 5776 was Sep 13 2015, 19:07 and 9 chalakim.

For years before or after that, the code loops in either direction by quickly calculating the number of months (12 or 13) in each Hebrew year (actually using this), and then multiplying that by the `moladInterval` which it defines as `765433e4 / 3`. This number is basically 29 days, 12 hours, and 793 chalakim in milliseconds.

The code then uses the same interval to adjust for the actual month that it is trying to calculate.

When outputting the result in text, the code determines the number of chalakim to display by taking the number of seconds, dividing it by 3.3 and then rounding to the nearest integer. Simple math says that this is incorrect - the correct approach would be to divide by 3 + (1/3).

Why? If there are 1,080 chalakim per minute, then each second = 1080 / 60 / 60 = 0.3 chalakim. So if we want to go from seconds back to chalakim we would divide by 0.3 which is the same as multiplying by 3 + (1/3) which is approximately 3.333333 with the decimals continuing, and not just 3.3.

I was unable to reproduce the examples you provided (if you provide your operating system and browser version I can further explore whether this might vary by each person's environment). More specifically, when I plug in the examples you gave at https://www.torahcalc.com/molad/, I obtain:

• Tammuz, year 1 = Sunday, May 30, -3760, 5:47 pm and 14 chalakim
• Av, year 1 = Tuesday, June 29, -3760, 6:31 am and 15 chalakim

The good news is that I was able to find other situations where I can reproduce the issue. On my system, one such example occurs in the year 121:

• Tishrei, year 121 = Thursday, September 1, -3641, 8:49 am and 13 chalakim
• Cheshvan, year 121 = Friday, September 30, -3641, 9:33 pm and 15 chalakim
• Kislev, year 121 = Sunday, October 30, -3641, 10:17 am and 15 chalakim

For the Cheshvan example, the precise result obtained on my system is -177010863970000.97. When we convert this to a date, we obtain 48 seconds. 48 divided by 3.3 rounds to 15, which is what their code is doing. If we instead divide by 48 by 3 + (1/3) we would round to 14 which would be correct.

Finally, it should certainly be noted that working backwards from a random date using this simplified approach is very much incorrect, for a number of potential reasons. As their own website notes:

Please note that dates before the adoption of the Gregorian calendar in 1752 may be innacurate. TorahCalc does not take into account the advancement of 11 days between 2 September 1752 to 14 September 1752. More info.

• I've found another very strange anomaly in the year 5608. Kisleiv has 17 chalokim and Teiveis has 4 chalokim. Do you know why this might be? Commented Jan 27, 2022 at 13:23
• For Kisleiv 5608 I see `Monday, November 8, 1847, 4:48 am and 2 chalakim` and for Teiveis I see `Tuesday, December 7, 1847, 5:32 pm and 3 chalakim`. Can you share your operating system and browser version? I have a feeling it may be dependent on this.
– yydl
Commented Jan 28, 2022 at 4:30