logic/correctness

Two Time Zones In One Flow

#20rare9 sightingsfirst seen September 2026

What goes wrong

One flow interprets a wall-clock value under two different time-zone rules (browser zone vs display override, application server zone vs database zone, UTC formatting vs the calendar window's own zone), so a value produced under one is read or rendered under the other and comes out shifted.

Example

The server runs in UTC and the database session in a European zone; a 'timestamp without time zone' written by one and read by the other is off by one or two hours.

Not to be confused with

Both zone choices are valid on their own but differ; not a half-open interval slip and not a DST gap or overlap within a single zone.

Discovered by

@sks24git GitHub

Field notes · 2

@sks24git2026-10-25
A new watchdog flagged any change request as stuck after an hour without a commit, but review and automated fix steps in the same pipeline take longer than that by design. Every healthy request would raise a paid alert.
Calibrate a stall threshold against the pipeline's own timeouts. Shorter than a normal step means false alarms.
Exclude known-busy states before timing silence. Quiet is not stuck.
@sks24git2026-09-10beat 3 review rounds
Every timestamp on the screen rendered in the user's chosen display zone, but the date picker parsed its input in the browser zone. Pick another zone and the window you schedule starts hours from the one you read.
One zone per screen, for input and output alike. A picker reading a zone the labels do not use ships a shifted window.
Test the form under a non-browser zone.