1659367 - Intl.DateTimeFormat.prototype.formatRange timezone format

Status: RESOLVED WORKSFORME

(Core :: JavaScript: Internationalization API, defect)

Description

[Thorin [:thorin]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

first result is same day, second result is a different day

	try {
		let date1 = new Date(Date.UTC(2007, 0, 10, 9, 0, 0)),
			date2 = new Date(Date.UTC(2007, 0, 10, 10, 0, 0)),
			date3 = new Date(Date.UTC(2007, 0, 20, 8, 0, 0))
		let f = Intl.DateTimeFormat(undefined, {weekday: "long", month: "long", day: "numeric",
			year: "numeric", hour: "numeric", minute: "numeric", second: "numeric", hour12: true, timeZoneName: "long"})
		console.log(f.formatRange(date1, date2) + "\n" + f.formatRange(date1, date3))
	} catch(e) {
		// not supported
	}

Actual results:

same day uses a different format for timezone

here's my timezone

• Wednesday, January 10, 2007, 10:00:00 PM GMT+13 – 11:00:00 PM GMT+13
• Wednesday, January 10, 2007, 10:00:00 PM New Zealand Daylight Time – Saturday, January 20, 2007, 9:00:00 PM New Zealand Daylight Time

here's with RFP enabled

• Wednesday, January 10, 2007, 9:00:00 AM UTC – 10:00:00 AM UTC
• Wednesday, January 10, 2007, 9:00:00 AM Coordinated Universal Time – Saturday, January 20, 2007, 8:00:00 AM Coordinated Universal Time

Expected results:

If this is by design, then that's cool :) Just want to clarify

Comment 1

[André Bargull [:anba]]

Yes, that's by design. A while ago I've filed https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/21 and https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/22 which are both kind of related to this issue. In https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/22#issuecomment-671772061 the proposal champion confirmed that the output style can't be determined upfront, so depending on the input range different format strings may be returned. But I can definitely forward this bug report to the proposal GitHub repo as user feedback.

Comment 2

[Thorin [:thorin]]

Thanks for the info and links :) I noticed the same implementation on chrom/ium. I'm not bothered by it at all ... I'm using it in fingerprinting tests [1], just wanted some clarity. It's not a complaint or even feedback. Feel free to close
[1] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#language

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Waldo, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Jason Orendorff [:jorendorff]]

Marking this closed, as it's not exactly a bug, or at least not a bug in the implementation.