Astro:sun:night#start channel UNDEF and others too

Thank you very much for your effort in the research for a solution @wmarkow . I tried to follow this thread during my holidays. A lot of things have been mentioned and taken into account for a proper solution. From my point of view we should not truncate the times to midnight for any phase. We should do it similar to the NIGHT phase. Most important reason are the false events. I do not think it is a good solution to suppress events which could lead to confusion or false positives too. But IIRC even when choosing this approach it could be possible to see two ASTRO_DUSKs per day. Couldn’t it? Thus handling two similar phases per day must be possible. Which matches your first proposal.

2 Likes

I have a small update on the issue. Indeed a midnight truncate is some kind of artifical border. It well good to understand for humans, because the date changes at midnight, however this midnight border is not consistent with Earth natural rotation. A better “truncate moment” would be a “true midnight”, which is moment where the Sun has the lowest elevation below horizont. However on some places at some specific time the Sun never goes under horizon, however at true midnight it will have the lowest elevation.
For example - if night is present - then an evening night ends always at true midnight and a morning night begins always at true midnight. Another example: if a night is not present but astro twilight is present, then astro dusk always ends at true midnight, and astro dawn starts always at true midnight, and so on.

Astro has one special range which is called NIGHT. The specific property of this range is that it overlaps a two dates (before midnight and after midnight).

To overcome all of those events Astro library need to make a special care for calculation of events:

  • if the current time is between midnight and true midnight then it mean that the current sun phase is EVENING_NIGHT of the previous day (if night is present at this specific day) and Astro shouold deliver the NIGHT as a night which passes between those two dates. Also the EVENING_NIGHT should be delivered as from yesterday date, and MORNING_NIGHT should be delivered as from today date
  • if the current time is after true midnight then we are currently in MORNING_NIGHT of current date, however we are still in the NIGHT between yesterday and today
  • if the current time is after current NIGHT finishes, then it mean that we are in ASTRO_DAWN but astro should recalculate the NIGHT range to bo the next night available (so between current date and tomorrow). MORNING_NIGHT should be from current date and EVENING_DATE should be also from current date.
  • a special care must be taken if we currently are in a full daylight like in north subpolar locations at June. Then Astro could calculate the real daylight start time and end time and also the duration for this can give months, like @rossko57 has previously asked.

I have managed to rework Astro library to support those cases mentioned above. Some kind of refactoring needed to be done. Previously everything was calculated by a SunCalc calculator, which was hard for testing. After refactoring and reimplementing the following calculators are available in Astro:

  • SunPositionCalc refactored from SunCalc - it calculates the sun position
  • SunRadiationCalc refactored from SunCalc - it calculates sun radiation info
  • SunDailyEventsCalc refactored from SunCalc - it calculates a basic daily sun events, like sun rise, sun set, astro dawn start, nautic dawn start, civil dawn start, noon, true midnight, and so on
  • SunDailyRangesCalc - implemented by me. Basing on SunDailyEventsCalc it creates a sun daily ranges, so it is able to deliver correct values for NIGHT, MORNING_NIGHT, EVENING_NIGHT, ASTR_DAWN, and so on. It takes care for midnigh, true midnight transitions, full daylight, etc.
  • SunCalc I left for backward compatibility but it is refactored and it is more or less an aggregation of all other calculators.

Moreover I have implemented unit tests to cover the special cases:

  • test for Murmansk location Russia north subpolar for a full daylight in June
  • test for Alert location in Canada (also subpolar) for a full daylight in June and night and astro twilight in December
  • test for McMurdo location in Antarctica (south subpolar) for a full daylight in December

Those changes are available in my astro-fixes branch.
One thing is still missing, the astro events must be recalculated not only after midnight, but also shortly after true midnight and shortly after night finishes (if night is present).

Please let me know what you think. If would be good if you guys could build the astro binding at test it in your environments.