Fix day label off-by-one in parse_open_meteo_forecast

[malawto]

Fix day label and moon phase off-by-one in parse_open_meteo_forecast

Open-Meteo daily time values are date strings (e.g. "2026-02-27"), not datetimes. The previous code parsed them with .replace(tzinfo=timezone.utc).astimezone(tz), which stamped them as UTC midnight and then shifted them into local time — rolling each date back to the previous evening. This caused every forecast card to display the wrong day label and the wrong day's high/low temperatures.

A timedelta(days=1) offset on target_date in the moon phase calculation was silently compensating for this same bug, keeping moon phases accidentally correct.

This PR fixes the date parsing by using date.fromisoformat() directly, and removes the timedelta(days=1) offset that was masking the original error. The result is correct day labels, correct temperatures in each forecast card, and correct moon phases.

[phattmatt]

Hi @malawto,

Thanks for the fix — the diagnosis looks correct and this still appears relevant against current main.

One small cleanup resulting from this change: dt is now only used to calculate timestamp, and timestamp was already unused in this function.

Could you remove both of these lines?

dt = datetime.combine(local_date, datetime.min.time()).replace(tzinfo=tz)
...
timestamp = int(dt.replace(hour=12, minute=0, second=0).timestamp())

This would also avoid introducing the new .replace(tzinfo=tz) timezone assignment, which isn't needed now that the daily Open-Meteo value is being handled correctly as a date.

It would also be useful to add a small regression test using a timezone west of UTC, such as America/New_York, to verify that a date like 2026-02-27 remains labelled Fri rather than being shifted back to Thu.

Otherwise, the fix looks good to me.

Thanks again,

Matt.