2085525 - Intl.DateTimeFormat formatRange prints AM/PM instead of the dayPeriod when timeZoneName is set

Status: UNCONFIRMED

(Core :: JavaScript: Internationalization API, defect, P3)

Description

[Craig Curtis]

Attachment: Firefox 158.0.1 About dialog and console output

Steps to reproduce

Run this in the Web Console:

const opts = { hour: "numeric", dayPeriod: "short", timeZone: "America/New_York", timeZoneName: "shortOffset" };
const start = new Date(Date.UTC(2024, 1, 29, 15)); // 10:00 in New York
const end = new Date(Date.UTC(2024, 1, 29, 17));   // 12:00 in New York
const dtf = new Intl.DateTimeFormat("en-US", opts);
console.log(dtf.formatRange(start, end));
console.log(dtf.format(start), "|", dtf.format(end));
console.log(new Intl.DateTimeFormat("en-US", { ...opts, hourCycle: "h12" }).formatRange(start, end));

Actual results

10 AM GMT-5 – 12 PM GMT-5
10 in the morning GMT-5 | 12 noon GMT-5
10 in the morning GMT-5 – 12 noon GMT-5

The first line, formatRange, uses AM and PM. A single format of each date (line 2) uses the day period: "in the morning" and "noon". formatRangeToParts gives no dayPeriod part with that text either.

Line 3 asks for hourCycle: "h12" and gets the day period. But en-US already resolves to h12 without it (check dtf.resolvedOptions().hourCycle), so lines 1 and 3 have the same resolved options and give different results.

Expected results

10 in the morning GMT-5 – 12 noon GMT-5
10 in the morning GMT-5 | 12 noon GMT-5
10 in the morning GMT-5 – 12 noon GMT-5

The range should use the same day period as format gives for each date. Chrome and Node print this.

ECMA-402 FormatDateTimeRange (§11.5.8) picks the range pattern from the resolved options, so lines 1 and 3 should give the same result.

It also happens with timeZoneName set to short or long, and when minute is set. It does not happen when timeZoneName is left out, or when hourCycle: "h12" or hour12: true is given.

Found in Firefox 158.0.1 on macOS (Apple silicon, aarch64). Also seen in Firefox 155.0.