Proposal-temporal: Time zone and DateTime.prototype.toLocaleString

[sffc]

I think the current semantics are that we use Intl's time zone (the environment time zone) when formatting a DateTime.

However, this could produce unexpected results:

// I start in America/Chicago
console.log(Temporal.now.timeZone());  // "America/Chicago"

// I create a local time in America/New_York
const dateTime = Temporal.now.absolute().inTimeZone("America/New_York");

// Now I format it.  Oops!  The wall clock time is in America/New_York,
// but the time zone rendered in the string is America/Chicago.
console.log(dateTime.toLocaleString("en", { timeZoneName: "long" }));

Possible resolutions:

1. Ignore. This is a programmer error.
2. Forbid a time zone from being displayed in DateTime.prototype.toLocaleString.
3. Add a time zone slot to the data model (#569).

[ptomato]

This doesn't seem to be the case, I don't get any time zone when formatting Temporal.DateTime:

> dt = Temporal.now.absolute().inTimeZone('America/Chicago')
DateTime [Temporal.DateTime] {}
> dt.toString()
'2020-05-15T17:34:45.102062856'
> dt.toLocaleString()
'2020-05-15, 5:34:45 p.m.'

[sffc]

You have to opt in to see the time zone.

.toLocaleString("en", { timeZoneName: "long" })

I'll update the OP and mark these two comments as outdated.

[ptomato]

I see the point about opting in. I am strongly in favour of option 2 (doesn't preclude option 3 if we decide so on that issue).

Mainly because it's in line with what other types do, in the case where you request information that they don't have:

> Temporal.now.time().toLocaleString('en', { month: 'numeric' })
'3:54:52 PM'

[justingrant]

IMHO, the current behavior (1) is not OK to ignore. If DateTime doesn't know about its time zone, then formatting it should not include a timezone. Especially not the wrong timezone!

Seems like (2) is the right behavior for a timezone-less class.

Nice to see another use-case that'd get easier with a ZonedAbsolute. ;-)

Related: #577

[ptomato]

I've gone ahead and made a pull request for option 2 since I haven't heard any opposition.

[sffc]

Should we render the time zone if it is specified explicitly?

console.log(dateTime.toLocaleString("en", { timeZoneName: "long", timeZone: "Asia/Singapore" }));

[ptomato]

I'd say no, since it could be ambiguous — this was what @justingrant was referring to in #577.

[ptomato]

@sffc Do you feel strongly about rendering the time zone if it is specified explicitly? I think that it should be treated the same as e.g. console.log(Temporal.now.time().toLocaleString("en", { month: 'long' })) which currently ignores the month option since it doesn't exist in the context of Temporal.Time. Feel free to reopen if you disagree.

[sffc]

I'm fine with this conclusion. Your reasoning sounds good.