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

Set the timezone per machine, sintra to Europe/Paris #109

Closed
padreug wants to merge 1 commit from fix/sintra-timezone into dev
pull from: fix/sintra-timezone
merge into: aiolabs:dev
Conversation 1 Commits 1 Files changed 2 +19 -2
padreug commented 2026-09-24 10:27:14 +00:00
Owner
Copy link

Every machine inherited America/Guatemala from the shared base config, which is right for douro and tejo and wrong for sintra in France. It read six hours behind, so its journal timestamps had to be converted by hand against anything on the relay.

The clock is not cosmetic here. system.autoUpgrade's dates = "04:00" is local time, so the zone decides when the nightly rebuild restarts the app and the Fujitsu dispenser runs its audible init routine. On sintra that was firing at 10:17 in the morning, in the room, rather than at 4am.

timeZoneForModel mirrors fiatCodeForModel and lists only the exceptions. The base config keeps America/Guatemala as the fleet default, now under mkDefault so a per-model value wins without mkForce.

Verified by eval rather than by reading the diff:

sintra-installed     Europe/Paris
douro-installed      America/Guatemala
batm3-installed      America/Guatemala
tejo-installed       America/Guatemala

batm3 is deliberately left alone. It is USD and in the field, and I do not know where it is.

Deploy note: this only takes effect on sintra's next rebuild, and the upgrade that applies it still runs on the old zone. So the first 04:00 CEST upgrade is the night after.

Every machine inherited `America/Guatemala` from the shared base config, which is right for douro and tejo and wrong for sintra in France. It read six hours behind, so its journal timestamps had to be converted by hand against anything on the relay. The clock is not cosmetic here. `system.autoUpgrade`'s `dates = "04:00"` is local time, so the zone decides when the nightly rebuild restarts the app and the Fujitsu dispenser runs its audible init routine. On sintra that was firing at 10:17 in the morning, in the room, rather than at 4am. `timeZoneForModel` mirrors `fiatCodeForModel` and lists only the exceptions. The base config keeps `America/Guatemala` as the fleet default, now under `mkDefault` so a per-model value wins without `mkForce`. Verified by eval rather than by reading the diff: ``` sintra-installed Europe/Paris douro-installed America/Guatemala batm3-installed America/Guatemala tejo-installed America/Guatemala ``` batm3 is deliberately left alone. It is USD and in the field, and I do not know where it is. **Deploy note:** this only takes effect on sintra's next rebuild, and the upgrade that applies it still runs on the old zone. So the first 04:00 CEST upgrade is the night after.
Every machine inherited America/Guatemala from the shared base config,
which is right for douro and tejo and wrong for sintra in France. It read
six hours behind, so its journal timestamps had to be converted by hand
against anything on the relay.

The clock is not cosmetic here. system.autoUpgrade's `dates = "04:00"` is
local time, so the zone decides when the nightly rebuild restarts the app
and the Fujitsu dispenser runs its audible init routine. On sintra that
was firing at 10:17 in the morning, in the room, rather than at 4am.

timeZoneForModel mirrors fiatCodeForModel and lists only the exceptions.
The base config keeps America/Guatemala as the fleet default, now under
mkDefault so a per-model value wins without mkForce. Verified by eval:
sintra resolves to Europe/Paris, douro, tejo and batm3 are unchanged.

batm3 is deliberately left alone. It is USD and in the field, and I do
not know where.
padreug commented 2026-09-24 21:12:17 +00:00
Author
Owner
Copy link

Superseded by #111, which solves this more narrowly.

Setting the system timezone turned out to be the wrong lever. Its two consumers here are the upgrade window, which #111 handles directly with a timezone suffix on the calendar spec, and the operator wanting correct transaction times, which never needed the machine at all since the dashboard renders in the reader's own browser locale. That leaves only a technician reading the journal at the machine, and for correlating against relay created_at stamps UTC is easier anyway.

Closing in favour of #111. The fleet clock stays untouched.

Superseded by #111, which solves this more narrowly. Setting the system timezone turned out to be the wrong lever. Its two consumers here are the upgrade window, which #111 handles directly with a timezone suffix on the calendar spec, and the operator wanting correct transaction times, which never needed the machine at all since the dashboard renders in the reader's own browser locale. That leaves only a technician reading the journal at the machine, and for correlating against relay `created_at` stamps UTC is easier anyway. Closing in favour of #111. The fleet clock stays untouched.
padreug closed this pull request 2026-09-24 21:12:23 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
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!109
No description provided.