The console has no time zone of its own: dates follow whatever zone the server process runs in #151

New Issue

2026-09-28T04:19:17Z

cgalo5758 commented

2026-09-28 04:19:17 +00:00

Every date and time the console shows is formatted in the server process's local zone. The same invoice therefore shows a different date depending on where the deployment runs: a container in UTC and a laptop in Central time disagree near midnight. The console can also disagree with the payment provider's own documents. Stripe's invoice and receipt can say Sep 28 for a payment the console dates Sep 27. Nothing records which zone a date is in, and no person can choose one.

What exists today

Formatting. About forty call sites format their own dates with time.Format and a hand-written layout: "Jan 2, 2006", "Jan 2, 2006 3:04 PM", "Jan 2, 2006 15:04 MST" (for example member_invoices.go, operator.go, operator_billing.go, operator_enrollment.go, member_domains.go). Most show no zone. A few print an abbreviation. The clock mixes 12-hour and 24-hour.
Input. The grant valid-until picker sends the browser's UTC offset for the picked date (grant-valid-until-tz.js) and falls back to the server's zone without it (operator_enrollment.go, around the ParseInLocation calls).
Design. design/data-model.md gives users a timezone column ("Preferred timezone for date display") and a locale column. Neither is built.
Kinds of value. Some values are instants (paid at, failed at, transitions). Some are calendar dates that should not move with a zone (due dates, service periods, a grant's end date). Today both kinds go through the same formatting.

What time zone management could cover

A deployment default zone, set by the operator, used when nothing more specific is known.
A per-person preference (the designed users.timezone), with the browser's zone as a fallback before one is set.
One formatting path that takes the viewer's zone, and a stated rule for which values are instants and which are calendar dates.
Inputs read in the same zone the page displays.
Locale for date and number formats (the designed users.locale), whether that comes now or later.
Where the console's dates meet the provider's (invoice issue and paid dates, service periods), a stated relationship to the zone the provider prints its documents in.

Related: #150 (invoice detail dates and service periods).

Every date and time the console shows is formatted in the server process's local zone. The same invoice therefore shows a different date depending on where the deployment runs: a container in UTC and a laptop in Central time disagree near midnight. The console can also disagree with the payment provider's own documents. Stripe's invoice and receipt can say Sep 28 for a payment the console dates Sep 27. Nothing records which zone a date is in, and no person can choose one. ## What exists today - **Formatting.** About forty call sites format their own dates with `time.Format` and a hand-written layout: `"Jan 2, 2006"`, `"Jan 2, 2006 3:04 PM"`, `"Jan 2, 2006 15:04 MST"` (for example `member_invoices.go`, `operator.go`, `operator_billing.go`, `operator_enrollment.go`, `member_domains.go`). Most show no zone. A few print an abbreviation. The clock mixes 12-hour and 24-hour. - **Input.** The grant valid-until picker sends the browser's UTC offset for the picked date (`grant-valid-until-tz.js`) and falls back to the server's zone without it (`operator_enrollment.go`, around the `ParseInLocation` calls). - **Design.** `design/data-model.md` gives `users` a `timezone` column ("Preferred timezone for date display") and a `locale` column. Neither is built. - **Kinds of value.** Some values are instants (paid at, failed at, transitions). Some are calendar dates that should not move with a zone (due dates, service periods, a grant's end date). Today both kinds go through the same formatting. ## What time zone management could cover - A deployment default zone, set by the operator, used when nothing more specific is known. - A per-person preference (the designed `users.timezone`), with the browser's zone as a fallback before one is set. - One formatting path that takes the viewer's zone, and a stated rule for which values are instants and which are calendar dates. - Inputs read in the same zone the page displays. - Locale for date and number formats (the designed `users.locale`), whether that comes now or later. - Where the console's dates meet the provider's (invoice issue and paid dates, service periods), a stated relationship to the zone the provider prints its documents in. Related: #150 (invoice detail dates and service periods).

cgalo5758 added the

kind

design

area/operator-ui area/member-ui labels 2026-09-28 04:19:17 +00:00

cgalo5758 commented

2026-10-01 04:43:04 +00:00

The organization page's grants table shows Activated and Valid until as a date with a time under it, and nothing says which zone that time is in. The fix needs a way to show the zone where it matters, not only a rule for which zone the console uses. Without it, an operator cannot tell whether "03:15" under Activated is their time, the server's, or UTC.

cgalo5758 referenced this issue from a commit

2026-10-02 00:49:58 +00:00

Read invoices back from Stripe and archive the change

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#151