Known Limitations
This page states plainly what this engine does not fully control, so nobody discovers a platform dependency the hard way.
Known limitations
A specification that omits what it does not fully control would be making a promise the engine does not keep. These are the host-platform dependencies this phase accepted rather than mitigated, each with the decision that ruled out the alternative:
- Timezone identifier recognition and DST transition data come from the host platform. A date/ time is an engine-owned value type — a UTC instant plus the timezone it is interpreted in — never a bundled timezone database, because Temporal (the right long-term answer) is not reliably available across Node 24 and every supported browser yet, and a polyfill would be a runtime dependency this package cannot take without bundling it internally. A Node build and a browser build on different platform versions can therefore disagree about an unusual zone or a recently-changed transition rule. The authoritative save-time check is always the server's; the fixtured zones this phase tests are covered in both runtimes.
- Case mapping (
UPPER/LOWER) follows the host's own Unicode version, for the same build-portability reason as timezone data — locale-independent, but not version-pinned. - A JSON number carrying more digits than a host double's precision has already lost them before
the engine ever sees the value — see the JSON ingestion contract
for the documented remedy (the string-plus-
PARSENUMBERidiom). - The isomorphism claim (ENG-16) is exercised in CI against Node and Chromium — two runtimes that share one JavaScript engine family, not three independent ones. The cross-engine half of the regular-expression subset's portability claim rests on the constructs' own specification and on the exclusions the subset makes, not on execution inside SpiderMonkey or JavaScriptCore in this phase's own CI. No browser support matrix exists in source to test against — a product decision this phase deliberately does not invent.