Publish the API's effective timezone and tolerate an older snapshot payload
TZ-002: with no zone stored the API reads its clock in the host's local time, but the panel fell back to Home Assistant's zone and the admin app to the browser's, so dates could disagree near midnight. The API now names the zone it actually uses (api/host_zone.py: the stored zone, else the host's own IANA zone from TZ, /etc/localtime or /etc/timezone) and publishes it as the panel snapshot's `timezone` and the admin settings' read-only `effective_timezone`. Both cards and the admin app format in that one zone; Home Assistant's or the browser's zone applies only when none is published. TZ-003: snapshot_from_api_payload reads `timezone` with a "" default, so an integration upgraded ahead of its API keeps refreshing against the pre-change payload. Task 7e173881-fb99-426f-a2f0-2678439ffc39 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -97,8 +97,9 @@ class NestQuestSnapshot:
|
||||
children: tuple[ChildDaySnapshot, ...]
|
||||
cycle_day: int
|
||||
#: The application timezone the admin stored (``""`` when unset —
|
||||
#: the host's local time). The panel cards format their visible
|
||||
#: date and clock in it; it never re-resolves the day itself.
|
||||
#: the host's local time; the API publishes its effective zone in
|
||||
#: its place, api/host_zone.py). The panel cards format their
|
||||
#: visible date and clock in it; it never re-resolves the day itself.
|
||||
timezone: str = ""
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user