aiolabs/bitspire
9
0
Fork 0
Code Issues 52 Pull requests 2 Projects Releases Packages Wiki Activity Actions

Give the upgrade window its own timezone, not the system #111

Merged
padreug merged 1 commit from fix/upgrade-window-timezone into dev 2026-09-25 05:44:54 +00:00
Conversation 0 Commits 1 Files changed 1 +31 -1
padreug commented 2026-09-24 21:12:08 +00:00
Owner
Copy link

Replaces #109, which set the system timezone per machine. This does the narrower thing.

An upgrade restarts the app and the Fujitsu dispenser runs an audible init routine when it does. On sintra that was firing at 10:17 in the morning, in the room, because dates = "04:00" is local time and every machine inherits America/Guatemala from the shared base config.

systemd 252+ accepts a timezone suffix on a calendar spec, and system.autoUpgrade.dates passes straight through to OnCalendar. So the timer can follow Europe/Paris and its DST while the system clock stays a fleet default nobody has to maintain per host.

Worth saying why the system timezone turned out not to be the right lever. It has exactly two consumers that matter here. The upgrade window, which this handles directly. And the operator wanting correct transaction times, which never needed the machine at all: the dashboard renders in the reader's own browser locale, which is why the cassettes tab read correctly while the journal did not. What is left is a technician reading the journal at the machine, and for correlating against relay created_at stamps UTC is easier anyway.

Verified by resolving the config for all four hosts:

sintra  dates=04:00 Europe/Paris  tz=America/Guatemala
douro   dates=04:00               tz=America/Guatemala
batm3   dates=04:00               tz=America/Guatemala
tejo    dates=04:00               tz=America/Guatemala

and against systemd-analyze on sintra itself, where 04:00 Europe/Paris resolves to 02:00 UTC and 04:00 America/Guatemala to 10:00 UTC.

A trap, documented in the comment because it nearly caught me. The same check under nix-shell -p systemd silently computes every named zone as UTC, while still echoing the zone back in its "Normalized form" line. It looks accepted and is wrong. The sandbox cannot resolve named zones and fails soft. Test on a real system.

The map is keyed on model like fiatCodeForModel, and inherits the same limitation, which the comment records: model is a hardware model and only doubles as host identity while there is one machine of each. A second sintra in another country needs this keyed on host, along with the fiat code and the app build that bakes it in.

Deploy note: the timer's last-run stamp is newer than the new window's most recent occurrence, so Persistent=true should not cause a catch-up fire on switch. Worth a glance at systemctl list-timers nixos-upgrade afterwards.

Replaces #109, which set the system timezone per machine. This does the narrower thing. An upgrade restarts the app and the Fujitsu dispenser runs an audible init routine when it does. On sintra that was firing at 10:17 in the morning, in the room, because `dates = "04:00"` is local time and every machine inherits `America/Guatemala` from the shared base config. systemd 252+ accepts a timezone suffix on a calendar spec, and `system.autoUpgrade.dates` passes straight through to `OnCalendar`. So the timer can follow Europe/Paris and its DST while the system clock stays a fleet default nobody has to maintain per host. Worth saying why the system timezone turned out not to be the right lever. It has exactly two consumers that matter here. The upgrade window, which this handles directly. And the operator wanting correct transaction times, which never needed the machine at all: the dashboard renders in the reader's own browser locale, which is why the cassettes tab read correctly while the journal did not. What is left is a technician reading the journal at the machine, and for correlating against relay `created_at` stamps UTC is easier anyway. Verified by resolving the config for all four hosts: ``` sintra dates=04:00 Europe/Paris tz=America/Guatemala douro dates=04:00 tz=America/Guatemala batm3 dates=04:00 tz=America/Guatemala tejo dates=04:00 tz=America/Guatemala ``` and against `systemd-analyze` on sintra itself, where `04:00 Europe/Paris` resolves to 02:00 UTC and `04:00 America/Guatemala` to 10:00 UTC. **A trap, documented in the comment because it nearly caught me.** The same check under `nix-shell -p systemd` silently computes *every* named zone as UTC, while still echoing the zone back in its "Normalized form" line. It looks accepted and is wrong. The sandbox cannot resolve named zones and fails soft. Test on a real system. The map is keyed on model like `fiatCodeForModel`, and inherits the same limitation, which the comment records: model is a hardware model and only doubles as host identity while there is one machine of each. A second sintra in another country needs this keyed on host, along with the fiat code and the app build that bakes it in. Deploy note: the timer's last-run stamp is newer than the new window's most recent occurrence, so `Persistent=true` should not cause a catch-up fire on switch. Worth a glance at `systemctl list-timers nixos-upgrade` afterwards.
An upgrade restarts the app and the Fujitsu dispenser runs an audible
init routine when it does. On sintra that was firing at 10:17 in the
morning, in the room, because `dates = "04:00"` is local time and every
machine inherits America/Guatemala from the shared base config.

The obvious fix is to set the system timezone per machine. This does the
narrower thing instead: systemd 252+ accepts a timezone suffix on a
calendar spec, so the timer follows Europe/Paris and its DST while the
system clock stays a fleet default nobody maintains per host. The only
other consumer of machine-local time is a technician reading the journal
at the machine, and for correlating against relay created_at stamps, UTC
is easier anyway.

The operator dashboard never needed this. It renders timestamps in the
reader's own browser locale, which is why the cassettes tab read
correctly while the journal did not.

Verified by resolving the config for all four hosts, and against
systemd-analyze on sintra itself: 04:00 Europe/Paris is 02:00 UTC in
summer, 04:00 America/Guatemala is 10:00 UTC.

A warning is in the comment because it nearly caught me: the same check
under `nix-shell -p systemd` silently computes EVERY named zone as UTC
while echoing the zone back in its normalized form. It looks accepted and
is wrong. Test on a real system.
padreug deleted branch fix/upgrade-window-timezone 2026-09-25 05:44:54 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/bitspire!111
No description provided.