[jelic-nikola]

Fixes #1342.

Problem

With culture-sensitive formatting enabled, Culture.setDefaultTimezone, setNumberCulture, setDateTimeCulture and setDefaultCurrency had no effect on formats that had already been used. Those formats kept the settings from their first use. Only setCulture worked.

Importing NumberField or MonthPicker enables culture-sensitive formatting, so apps that use these widgets are affected.

Cause

In culture-sensitive mode, built formatters and compiled expressions and templates are cached on the default culture's cache object, together with the NumberCulture and DateTimeCulture they were built from. The setters called invalidateCache(), which bumps the global cache identifier and clears the global expression and template caches, but not the culture's own cache. setNumberCulture and setDateTimeCulture also dropped their culture object, but the formatters built from it stayed cached. setCulture worked because it replaces the whole cache.

Fix

Culture.invalidateCache() now also resets the default culture's cache, the same reset setCulture already did. Every setter calls invalidateCache(), so this fixes all of them with one change. The per-setter delete lines and the separate reset in setCulture were redundant and are removed.

The issue suggested deleting the cached items in each setter instead, which has the same effect but needs a change in each setter.

Impact

• After a setter call, formats, expressions and templates are rebuilt on next use. In a benchmark, rebuilding about 300 expressions and templates took about 5 ms. Setter calls already make every widget recompute its data on the next render.
• setDefaultDateEncoding now also resets the cache.
• Cultures created with createCulture keep their own cache. The setters didn't affect them before and still don't.

Not changed

• A runtime culture change doesn't reach tpl or expr props of widgets that already exist, because those are compiled when the widget is created. This was already the case for setCulture.

Testing

• New Culture.spec.ts with two tests, both failing without the fix: the timezone case from the issue (12:00 → 21:00), and a check that all four setters drop the cached formatters. The spec doesn't call enableCultureSensitiveFormatting(), because it can't be switched off and breaks util/Format.spec.ts and exprHelpers.spec.ts in the same run.
• Full cx suite, type check and build pass.
• Litmus: litmus/bugs/CultureSettersAfterFirstUse.js, loaded from litmus/index.js. Flip the switch: the four fields change (12:00 → 21:00, 04/24/2026 → 24.04.2026, 1,234.56 → 1.234,56, $1,234.56 → 1.234,56 €) and change back when it's flipped off. Before the fix they kept their first values.

[mstijak]

Thanks for the thorough analysis. Closing in favor of #1344, which takes the same idea (reset the default culture's cache when a setting changes) but does it in the setters through a shared helper instead of in Culture.invalidateCache(), and also documents culture scopes (Restate detached culture={createCulture(...)}) for content that needs a different culture.