Culture.setDefaultTimezone() is ignored by date formats used before the call (culture-sensitive formatting)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- frontend, internationalization
Research direction
Start in packages/cx/src/ui/Culture.ts, where the setters clear cache.dateTimeCulture and cache.numberCulture but not cache.formatCache, and in ui/Format.ts where the format cache callback is set. Run the reproduction from the issue: after Culture.setDefaultTimezone('Asia/Tokyo'), Format.value should return "21:00" rather than "12:00". Done means the setters drop the cached formatters as the issue suggests, with a test covering a timezone change after a format has been used.
Written by the indexing model from the issue text.
Description
With culture-sensitive formatting enabled, changing the default timezone with Culture.setDefaultTimezone() has no effect on a date format that has already been used: it keeps formatting in the timezone that was current when it was first used.
Reproduction
import { Culture, Format, enableCultureSensitiveFormatting } from 'cx/ui';
enableCultureSensitiveFormatting();
const at = '2026-04-24T12:00:00Z';
Culture.setDefaultTimezone('UTC');
Format.value(at, 'datetime;HHmmN'); // "12:00"
Culture.setDefaultTimezone('Asia/Tokyo');
Format.value(at, 'datetime;HHmmN'); // "12:00", expected "21:00"
Observed with cx 26.9.3; the same code is on master (packages/cx/src/ui/Culture.ts).
Cause
Two values are cached on the culture object (getDefaultCulture().cache), and setDefaultTimezone() clears neither:
cache.dateTimeCulture—getDateTimeCulture()creates theDateTimeCulturewithdefaultTimezone: timezoneand caches it.cache.formatCache— with culture-sensitive formatting, built formatters are cached here (setGetFormatCacheCallbackinui/Format.ts), and eachdatetime/date/timeformatter closes over theDateTimeCultureit was built with.
setDefaultTimezone() only updates timezone and calls invalidateCache(), which changes the global cache identifier and clears the expression and string template caches — not the culture's own cache. Clearing only dateTimeCulture is not enough: the formatter in formatCache still holds the old culture. Clearing both gives the expected 21:00.
Likely the same for other setters (from reading the code, not tested)
setDateTimeCulture()deletescache.dateTimeCulturebut notcache.formatCache, so already used date formats keep the previous date culture.setNumberCulture()deletescache.numberCulturebut notcache.formatCache, so already used number / currency / percent formats keep the previous number culture.setDefaultCurrency()clears neither, so already used currency formats keep the previous default currency.
setCulture() is fine: it replaces the whole cache.
Suggested fix
In Culture, drop the cached formatters whenever a setting they depend on changes:
setDefaultTimezone():delete cache.dateTimeCultureanddelete cache.formatCachesetDateTimeCulture(),setNumberCulture(),setDefaultCurrency(): alsodelete cache.formatCache
Impact
Apps that change these settings at runtime and keep the page alive. We hit it rendering documents on a reused headless page: every render sets the timezone of the document being rendered, and every render after the first one on that page came out in the first document's timezone.
- Dominant language
- TypeScript
- Stars
- 492
- Forks
- 71
- Avg merge
- 8h 27m
- Merged PRs (30d)
- 6
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from codaxy/cxjs
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
feature request
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Similar issues
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
frostney/GocciaScript#1746 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
agilepathway/label-checker#739 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
CopilotKit/OpenBot#800 ·
Maintainers usually reply within 1 day
-
Endpoint links in the tag operations list are below the 24px target sizePossibly taken @AdzerKI claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
ehmpathy/rhachet-roles-bhuild#471 ·
Maintainers usually reply within 1 day