The Windows installer's embedded Python doesn't carry an IANA tz
database, and the stdlib zoneinfo has no system DB to read on Windows.
ZoneInfo("UTC") raises ZoneInfoNotFoundError on those installs, and
the new /api/local-backup/status endpoint 500s on the resulting
uncaught exception. Surfaced via a Windows traceback from a user's log:
File "...\backend\app\services\local_backup.py", line 32, in _local_zone
return ZoneInfo("UTC")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
_local_zone()'s try/except only covered the TZ-env branch — both
fallbacks unconditionally called ZoneInfo("UTC") and re-raised.
Fix (two parts):
1. services/local_backup.py — return type widened from ZoneInfo to
tzinfo, the UTC fallback is wrapped in its own try, and the
last-resort fallback returns datetime.timezone.utc (stdlib, no
IANA DB needed). str(timezone.utc) == "UTC" so the response shape
on /api/local-backup/status is unchanged. The astimezone call in
_calculate_next_run accepts any tzinfo — no other call sites
affected.
2. requirements.txt — pin tzdata>=2024.1; sys_platform == "win32" so
the next Windows installer build ships the IANA DB, and any non-
UTC TZ value (e.g. Europe/Berlin) resolves correctly. The stdlib
fallback can only ever give UTC. Linux/macOS unaffected by the
platform marker — they already have the system tz database.
The Scheduled Local Backups time-of-day picker was interpreted as UTC by
_calculate_next_run, so a UTC+3 user had to enter 18:00 to get a 21:00
local backup. The UI labeled the field "UTC" but it was still surprising.
Picker is now interpreted in the container's local timezone, resolved
from the TZ env var via zoneinfo.ZoneInfo (same source the Support page's
environment.timezone shows). UTC fallback when TZ is unset or
unrecognised. The /local-backup/status endpoint exposes the resolved
zone, and the UI renders it next to the field via a new
backup.localTimeHint i18n key with real translations in all 10
non-English locales.
One-time behaviour change for users who entered a UTC time as a
workaround: the first scheduled cycle after upgrade will run at their
local TZ offset earlier than expected. Re-enter the time as local once
and it is correct from then on. No migration is shipped; migrating
around a DST boundary would be ambiguous.
maziggy