suncalc
suncalc copied to clipboard
mourner
getMoonTimes reports unexpected values
When I checked this morning the moon times were reported as
{rise: Mon Jun 04 2018 00:56:27 GMT+0200 (CEST), set: Sun Jun 03 2018 09:44:07 GMT+0200 (CEST)} // note how set is in the past
While this may technically be correct I'd argue that the results are very unexpected. Wouldn't you expect that both moon rise and moon set are future moon rise and moon set? So, the function should report when the moon rises and sets next time, no? OR when it rose and set today but not a mix thereof.
@marcelstoer No I don't think it is a bug . Because the Moon sometimes sets in the start of day, then it rise again in the same day, then it never sets in the same day, so this code gives you the correct values for that day. Sorry for my bad English
As I said...it may technically be correct. It's just unexpected behavior for me - and others. As an engineer I strive to apply the "Principle Of Least Astonishment"[1][2] and in my opinion this is violated here.
I recently ported a SunMoon calc class (not this one) from Java to C++ for Arduino. That class, published at http://conga.oan.es/~alonso/doku.php?id=blog:sun_moon_position, suffers from the same "problem" as this implementation. And so does my initial port of course. Yet, when someone embedded that original class into a GUI application he/she applied the exact same "correction" I suggested here. It calculates all the properties for now-1d, now, and now+1d. Then it figures out what the "relevant" moon rise and set times are. Those are the values displayed to the user. Just sayin'...
@marcelstoer It is not problem at all, because it gives you the correct events of the moon in the day you have select it, so there is no need for any correction.
If you are looking for the Moon in the sky [from 00:00:00 to 23:59:59], it will set, then it will rise again (after ~12 hours), then it never sets before tomorrow. I think this is the correct method. If you add a day I think you should mention that day (not just view time). Thank you
Sorry for my bad English
@marcelstoer
The library in this blog http://conga.oan.es/~alonso/doku.php?id=blog:sun_moon_position
Not very accurate, because it calculates delta T in a wrong way
The problem is in these lines:
if (year < 1600) {
TTminusUT = 10535.328003326353 - 9.995238627481024 * x + 0.003067307630020489 * x2 - 7.76340698361363E-6 * x3 + 3.1331045394223196E-9 * x4 + 8.225530854405553E-12 * x2 * x3 - 7.486164715632051E-15 * x4 * x2 + 1.9362461549678834E-18 * x4 * x3 - 8.489224937827653E-23 * x4 * x4;
} else {
TTminusUT = -1027175.3477559977 + 2523.256625418965 * x - 1.885686849058459 * x2 + 5.869246227888417E-5 * x3 + 3.3379295816475025E-7 * x4 + 1.7758961671447929E-10 * x2 * x3 - 2.7889902806153024E-13 * x2 * x4 + 1.0224295822336825E-16 * x3 * x4 - 1.2528102370680435E-20 * x4 * x4;
}
It maybe accurate between 1950 - 2050 , but it is not accurate for after 500 years (for example). Test it in year (2500) TTminusUT = -8784.29 , and this is a very wrong value.