LunarCalendar Plugin does not show current day

[DavidOrtmann]

If I'm reading the code correctly, the current today method in the LunarCalendar plugin has a potential timezone problem:

Problem:

def today
  user.datetime_now.to_date
end

When the plugin is called at edge times (e.g., 00:15 CET for 1x/day refresh) and since the polling server is located in a different timezone, the .to_date conversion may return the wrong date. This leads to incorrect moon phase calculations, especially for users in timezones ahead of the server.

Impact:

• Wrong current moon phase
• Incorrect next full/new moon dates
• Inaccurate phase sequence display

I currently don't have a solution implemented, but I believe the user's UTC offset should be used to ensure the date calculation happens in the user's local timezone rather than the server's timezone.

[DavidOrtmann]

Exhibit A: The strange race condition is back (English text in German locale, top left corner), and even after force refresh today's date (July 9th) is not displayed as the current phase (Full Moon/Vollmond should be the Current Phase).

[DavidOrtmann]

Correction: This does not seem to be a timezone issue, since the date does not change even several hours into the day, when the rendering server definitely is on the correct day. However, the problem remains - the current day is not shown, even though the current phase is on the current day.

Here's another user reporting the same problem in this plugin: https://www.reddit.com/r/trmnl/s/J1pHWyIOpI

[DavidOrtmann]

Exhibit B: The plugin is exactly one day late (today is July 10th):

[ryanckulp]

@DavidOrtmann is this still an issue?

[DavidOrtmann]

Let me check this again on November 19/20, when the next phase is due.

[DavidOrtmann]

All phases have been working correctly these past weeks and days, closing.

[jefferios]

I am having this issue as my device says the day is -1.

[DavidOrtmann]

Revisiting this, because Lunar Calendar is still Top 20 for our most popular plugins, more popular than Screenshot. No surprise, we are seeing tickets about this from time to time.
Users report, for example, that the results of the plugin do not match online calendars.

I've learned some stuff along the way, e.g. that the dates for the different Moon Phases are different depending on location (which anyone who knows more about timezones is probably not surprised by):

(Notice first quarter is on a different day.)

We are accounting for that with user.datetime_now, but interestingly, the results are similar: Dates are sometimes one day off for the plugin.

I've quizzed Gemini about this, maybe this helps a bit:

Missing Timezone Compensation

A significant factor contributing to the one-day offset is the lack of timezone-aware calculations in the current implementation:

• Fixed Global Reference Point: The moon_age method uses a static Date.new(2000, 1, 6) as the anchor for a New Moon. Since Ruby's Date class does not store time or timezone information, the calculation implicitly assumes the lunar cycle starts at 00:00:00 UTC for every user regardless of their location.

• Local vs. Astronomical Time: While the plugin uses user.datetime_now.to_date to determine "today," it treats the moon's position as a linear progression of full days. Astronomical events like a Full Moon occur at a specific global timestamp; whether that event falls on July 9th or July 10th depends on the user's local offset from UTC.

• Lack of Longitudinal Adjustment: The current formula (days_since % LUNAR_MONTH_DAYS) does not account for the observer's geographic longitude. It essentially calculates the moon's age as if the entire world shared the same local time, leading to discrepancies when an astronomical phase transition occurs near the midnight boundary of the user's timezone.

• Precision Loss: By converting times to integers (.to_i) and rounding results (.round), the code discards the hourly precision necessary to correctly align the lunar phase with the user's calendar day.

Impact

The combination of a static 26-year-old reference point and the absence of timezone compensation explains why the "Current Phase" (e.g., Full Moon at age 14.9) remains active on the UI even after the calendar date has progressed for the user.

I'm also wondering if we could use an existing library or gem for more precision (https://github.com/elct9620/lunar_calendar or https://github.com/isee15/Lunar-Solar-Calendar-Converter)