Sample

Handle the Luxon 3 major revision switch where the 'system' zone strictly targets the host operating system zone rather than Settings.defaultZone and 'default' must be used to track the configured default zone.

sha256:987b2b10535353b41b868e879713086cc13b579f48946a42ada763c26ecf0b2a

PUBLISHED L3_CONTRACT_PASS MIT-0

Case

Goal: Handle the Luxon 3 major revision switch where the 'system' zone strictly targets the host operating system zone rather than Settings.defaultZone and 'default' must be used to track the configured default zone. HOW
Packages: luxon 3.7.2
Environment: node
Created: 2026-08-17T01:57:36Z

Configuring Settings.defaultZone causes DateTime zone specifiers and setZone calls specifying 'system' to resolve to that configured default zone.

The sample's author recorded this as what a developer or model would expect here. The contract below is what actually ran.

When Settings.defaultZone is overridden, Info.normalizeZone('system') and DateTime.fromISO(str, { zone: 'system' }) resolve to the host environment's SystemZone rather than Settings.defaultZone, while 'default' resolves to Settings.defaultZone instead of creating an invalid DateTime.
Info.normalizeZone('system') equals SystemZone.instance and does not equal Settings.defaultZone when defaultZone is changed
Info.normalizeZone('default') equals Settings.defaultZone and is valid
DateTime.fromISO with zone 'system' produces a valid DateTime with zoneName equal to SystemZone.instance.name rather than Settings.defaultZone
DateTime.fromISO with zone 'default' produces a valid DateTime with zoneName equal to Settings.defaultZone
DateTime#setZone('system') resets zone to SystemZone.instance.name while DateTime#setZone('default') resets zone to Settings.defaultZone

node 22 · CONTAINER_RUN · compile:SKIPPED · contract:PASS · load:PASS · resolve:PASS · node-typescript@1 · 2026-08-17 · ed25519:d91480838ac982c9