Displays moon as 100%@0:08 for two consecutive nights

[xandro0777]

right now, March 17th and 18th in central European winter time. Don't think that can be correct.. looks like time zone confusion?

Assuming the time means transit time there should not be any on the 17th.

[forrestguice]

You are correct there isn't any transit on the 17th - the times you see are both for the 18th.

The app needs to pick a single illumination value for a given day (and typically that's lunar noon) but in this case its "lunar noon tomorrow". This wasn't really an issue before the app also displayed @time afterward, but now it seems a little misleading.

I'm not sure what the best solution is.. maybe just omit the @time part when the transit doesn't occur, because the illumination value itself (as a daily value) is accurate.

EDIT.. another view of this edge case:

[xandro0777]

The illumination will be correct sometimes later on March 17th but it is clearly wrong at the indicated time (less than 98% compared to 100). If there is no transit that day it might be best to display the range of illumination value (98-100%) for the day or reverse if decreasing. Everything else would be somehow odd: giving the value at noon would be strange given that the moon is not observable at noon (afaics can only happen around full moon) , any other pick highly arbitrary.. not to mention users would be left guessing at which time that number was valid.

[forrestguice]

Yes, it is clearly wrong at the indicated time - the problem is we're showing a time without indicating its tomorrow. That @time was added because people were unclear about why the illumination on the main page was different from the dialog, but now it reveals this edge case (and how the app currently deals with it).

The illumination on the 17th and 18th is 100% when the moon is at its highest - on the 17th that just happens to occur on the wrong side of the date line (from timezone setting) - those dates basically share a lunar noon.

The suggested solutions are good. Displaying a range is one possibility (that I'm liking more and more). Also displaying the illumination at solar noon would make the problem 'go away', but as noted it would probably confuse people. I'm still leaning towards just omitting the @time - at least one day out of every month would just show % without any @time afterward - the remainder would indicate time of lunar noon.

[forrestguice]

hrm, this pattern always coincides with a full moon? Its the difference between showing 99% vs 100.

[xandro0777]

I think it is always around fm. For strange time zones there could be strange corner cases though. The range might be 96-100 if the time zone is not too far away from the apparent solar time.

[xandro0777]

Thinking about it a bit more - maybe it should always display the illumination as range for every day? It can make up to 10% difference and the exact value at transit time may be less useful in many cases.

[forrestguice]

That's the conclusion I've come to as well - it would be better to always display a range (and just eliminate any special cases). That range of values is wider (more interesting/useful) depending on the day.

The transit time doesn't appear anywhere else though, so continuing to display it means new UI somewhere.
I think these changes are something for v0.15.0 (along with other enhancements to the moon dialog). The next patch will just be the band-aid solution mentioned before (hiding the @time), a quick change to stop the app from miscommunicating the transit time.

[xandro0777]

On my devices it seems that the range and transit time would fit into the available space where the illumination and transit time is now, so maybe that doesn't even require any big UI changes?