jcoffey-dev
6ee918d15f
Everything stays UTC: ingest still records Unix nanoseconds, ClickHouse
still stores UTC, every API response is still RFC3339 with a Z, and
queries are evaluated exactly as before. This changes only how those
instants are written on screen, so two people in two timezones looking
at one log line see the same instant written two ways -- never two
different lines, and never a different sort order.
Where the preference lives differs by deployment, and the three cases
are genuinely different products rather than one with fallbacks:
- Local login: server-side per named user (display_timezone on users,
PUT /auth/timezone), so it follows the person across browsers and
survives logout. Self-service at the RoleViewer floor, same as the
password change -- a viewer is the role most likely to be *only*
reading logs, so gating it higher would make it useless.
- Public demo: sessionStorage, so every new session starts at UTC. A
shared account's visitors have nothing to do with each other.
- Neither: localStorage, since there's no per-user record to write to.
api/cmd/api/main.go now imports time/tzdata. The image is
distroless/static with no /usr/share/zoneinfo, so LoadLocation would
otherwise reject every real zone name and the validation would refuse
every valid input.
Two details worth knowing when reading $lib/time.ts. Sub-second digits
are copied verbatim from the source string rather than round-tripped
through a JS Date, which is millisecond-precision and would silently
drop six digits of a ClickHouse nanosecond timestamp; expanding a result
row shows the localized value and the full-precision UTC original
together. And chart axes format their own labels, because ECharts'
type: 'time' axis renders in the browser's zone with no override --
which today puts a chart's clock out of step with the table beside it.
Timestamps are detected by value, not by column name: query output is
arbitrary, so a column called "timestamp" holding something else must
not be mangled, and `stats max(timestamp) as newest` must still be
formatted.
Verified against real zones including both sides of a DST boundary
(America/New_York at -05:00 in January, -04:00 in July), a half-hour
offset, and date rollover.
24 lines
1.2 KiB
SQL
24 lines
1.2 KiB
SQL
-- Per-user display timezone: a *presentation* preference only.
|
|
--
|
|
-- Every timestamp in this system is and stays UTC -- ingest records
|
|
-- Unix nanoseconds, ClickHouse stores DateTime64 in UTC, and both the
|
|
-- query API and every JSON response continue to emit RFC3339 with a Z
|
|
-- offset. This column changes nothing about any of that. It only tells
|
|
-- the web UI which offset to render those instants in, so two users in
|
|
-- two timezones looking at the same log line see the same instant
|
|
-- written two different ways, never two different log lines.
|
|
--
|
|
-- Stored as an IANA zone name ('UTC', 'America/New_York', ...) rather
|
|
-- than a fixed numeric offset, because a fixed offset is wrong twice a
|
|
-- year for anywhere that observes DST -- the zone name is what carries
|
|
-- the rule, not just today's answer. Validated in Go against the
|
|
-- embedded tzdata (see api/localauth's handleSetTimezone) rather than
|
|
-- by a CHECK constraint: the valid set is the tz database's, which
|
|
-- Postgres would have no way to keep in sync here.
|
|
--
|
|
-- Default 'UTC' matches the "standardize on UTC" baseline -- a user who
|
|
-- never touches this setting sees exactly what they saw before it
|
|
-- existed.
|
|
ALTER TABLE users
|
|
ADD COLUMN IF NOT EXISTS display_timezone TEXT NOT NULL DEFAULT 'UTC';
|