Fix for incorrect results if local day is "tomorrow" in UTC #48
Conversation
…sDayTime wrongly shows false.
fixed compatibility issues
|
I use only the "isNighttime/isDaytime" method from the original ceeK/Solar package. And the result was sometimes wrong. Thank you @aaronfreimark ! |
|
@aaronfreimark in some extreme cases, there is no sunrise or sunset time (polar day or polar night), your fork fix will crash. date: 2021-05-08 18:38:00 +0000 When accessing isDaytime() with this example data, the "tomorrowSunSet" variable will be nil (returned from calculate() method) which will be unwrapped later in the following code:
Unwrapping the nil value leads to crashes. Is there a fix for this bug? Thanks. |
|
@benck were you ever able to resolve the bug you stated above? |
Fixes #40
This issue appears if the date/time given to calculate is already "tomorrow" at UTC. For example, I'm in New York City, which is GMT-5. If I calculate between 00:00 - 18:59 hrs local time, I get a correct result. But if I calculate 19:00-23:59 local time, Solar return's tomorrow's result. A test is included in this PR to demonstrate.
To fix, I added an optional timezone: parameter to Solar(). If timezone is not specified, UTC is assumed. This makes the patch backwards compatible. If timezone is included, the current time (in seconds) is offset by the time different between local and UTC. This ensures the calculations are done on the correct date, and not possibly "tomorrow's" date.