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.
Your Examples
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.
