Follow system timezone changes in message timeline formatters - #3276
Draft
sagestainsbys wants to merge 1 commit into
Draft
Follow system timezone changes in message timeline formatters#3276sagestainsbys wants to merge 1 commit into
sagestainsbys wants to merge 1 commit into
Conversation
The message timeline's Intl.DateTimeFormat instances were constructed once at module load, and a formatter snapshots the timezone it was constructed in. A long-running Buzz therefore kept rendering timestamps in the previous zone after the OS timezone changed (e.g. travelling between timezones), until a full restart. Cache the formatters per resolved timezone instead: instances are reused while the zone is stable and rebuilt when it changes. Signed-off-by: Sage Stainsby <sages@squareup.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
While travelling between the US and Australia I noticed Buzz kept rendering message timestamps in US time after my Mac had switched back to
Australia/Melbourne— only a full restart fixed it.Cause: the message timeline's
Intl.DateTimeFormatinstances indesktop/src/features/messages/lib/dateFormatters.tsare constructed once at module load, and a formatter snapshots the timezone it was constructed in. A long-running app therefore keeps formatting in the stale zone after the OS timezone changes underneath it.This change caches the formatters per resolved timezone instead: each call re-probes
Intl.DateTimeFormat().resolvedOptions().timeZone(cheap), reuses the cached instances while the zone is stable, and rebuilds them when it changes — so a timezone change is picked up without a restart.Scope notes:
en-US: the surrounding formatting logic is English-only (hard-coded ordinal suffixes, "Today"/"Yesterday", AM/PM stripping), so following the system locale is a bigger, separable change.en-USformatters at module level (features/home/ui/FeedSection.tsx,features/home/lib/inbox.ts,features/messages/ui/DraftsPanel.tsx,features/agents/ui/agentSessionUtils.ts,features/search/*,features/channels/lib/ephemeralChannel.ts) and have the same staleness; this PR fixes the message timeline, the most visible surface. Happy to follow up on the rest with the same pattern if maintainers agree.Related issue
None found — searched issues and PRs for timezone-related reports.
Testing
TZ=America/Los_Angeles, switches toTZ=Australia/Melbournemid-process, and asserts the rendered times move with the zone (fails against the previous module-level formatters).pnpm test: 3722/3722 pass.pnpm exec tsc --noEmitandpnpm check(biome + repo checks) clean.