Intl.DateTimeFormat timeZone option behavior during DST transition gaps

Intl.DateTimeFormat does not "resolve" non-existent local times because it does not accept local wall-clock time as an input. It exclusively formats a UTC epoch (a Date object or timestamp) into a localized string based on the provided IANA time zone identifier. Because every UTC instant exists, the API always produces a valid localized string derived from the underlying ICU (International Components for Unicode) data.

The Source of the Gap Ambiguity

The "gap" or "overlap" problem typically occurs during parsing (converting a local wall-clock string back into a UTC instant), not during formatting. Since the Intl object is designed for formatting, it avoids this logic entirely. When you pass a Date object to Intl.DateTimeFormat, the engine simply looks up the offset for that specific UTC instant in the ICU database and applies it.

Native Detection of Adjustments

There is no native method or configuration flag within the Intl object to detect if a formatted date falls within a DST transition gap or if an adjustment occurred. The API is a one-way transformation from an instant to a string; it does not maintain metadata about the transition state of the resulting wall-clock time.

Verification and Manual Detection

To determine if a specific UTC instant maps to a DST transition period, you must manually compare the UTC components with the formatted local components. This is best achieved using formatToParts() to avoid locale-specific string parsing.

const date = new Date('2023-03-12T07:30:00Z'); // Example UTC instant
const formatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  hour: 'numeric', 
  minute: 'numeric', 
  timeZoneName: 'short'
});

const parts = formatter.formatToParts(date);
console.log(parts);

By extracting the hour and minute from the parts and comparing them to the UTC equivalent, you can calculate the active offset. If the offset changes abruptly between two adjacent timestamps, you have identified the transition point.

Implementation Assumptions

• Engine Dependency: This behavior assumes a modern JavaScript environment (Node.js or evergreen browsers) using ECMA-402.
• ICU Data: Results depend on the ICU version bundled with the runtime. Different versions may resolve historical DST rules differently.

Note: To provide a more specific resolution for parsing behavior, please provide the specific JavaScript engine and version (e.g., Node.js v20 or Chrome 120) being used, as local-to-UTC parsing is implementation-specific.