Normative: Use DefaultTimeZone to get the local time zone for Date

[ptomato]

Currently, it is technically possible for the following two operations to
result in different local times and different time zones:

> date = new Date()
> date.toTimeString()
'13:43:47 GMT-0700 (Pacific Daylight Time)'
> new Intl.DateTimeFormat(undefined, {timeStyle: 'full'}).format(date)
'1:43:47 p.m. Pacific Daylight Time'

This is because Date gets its notion of the current system time zone from
the operation LocalTZA, while Intl.DateTimeFormat uses the operation
DefaultTimeZone from ECMA-402 to determine the current system time zone.

This is a normative change because there was previously no requirement for
these to be linked. However, they should definitely be linked, and no
implementation that includes ECMA-402 that I'm aware of has a discrepancy
between the two. This patch adds this requirement.

This is accomplished by removing LocalTZA (which was actually two
operations rolled into one, anyway) and redefining the LocalTime and UTC
operations in terms of DefaultTimeZone, which moves into ECMA-262, as well
as the two new operations GetNamedTimeZoneOffsetNanoseconds and
GetNamedTimeZoneEpochNanoseconds.

It essentially pushes the "implementation-definedness" of LocalTZA into
GetNamedTimeZoneOffsetNanoseconds, GetNamedTimeZoneEpochNanoseconds, and
DefaultTimeZone.

Although it is a normative change because it adds the requirement for Date
and Intl.DateTimeFormat to use the same default time zone, it should have
no other effects. Despite specifying what LocalTZA used to do in terms of
different operations, the observable effects are the same.

[ptomato]

@tc39/ecma262-editors This is the PR that we discussed in the editor call yesterday, arising from tc39/proposal-temporal#2171

I put all the new AOs together into the Date section, let me know if they need to go anywhere else. The number of new AOs is not too bad but if needed I can cut it down a bit more:

• RoundTowardsZero could instead be a mathematical function like floor
• We could remove the "these are the steps if your implementation only has UTC" parts of the implementation-defined AOs (maybe their utility is questionable?) and that would allow removing GetEpochFromISOParts as well.

[gibson042]

I have some comments around naming and incorrect references to Unix (cf. tc39/proposal-temporal#2175 ), but the bulk of this looks good.

[ptomato]

I've gone with this for now, but are you sure about having the "Temporal" name in there? It might be confusing since Temporal isn't part of the specification yet.

[gibson042]

Ahead of the Temporal proposal landing, "temporal" still makes sense as a generic adjective indicating relationship to time—necessary here because date and time representations can use , as a decimal separator and – as a negative sign, neither of which are true of non-temporal (i.e., non-time-related) numeric strings in ECMAScript.

[gibson042]

I just see a few more grammar points and stray references to IANA, and a possible improvement in operation naming.

[gibson042]

This reached consensus. The promised followup details regarding DST transitions:

The requirements are described in GetNamedTimeZoneEpochNanoseconds (which returns a List of nanoseconds since epoch for a specific time zone name and local time) similar to the current text in LocalTZA: https://arai-a.github.io/ecma262-compare/?pr=2781#sec-getnamedtimezoneepochnanoseconds (emphasis mine)

When the input represents a local time occurring more than once because of a negative time zone transition (e.g. when daylight saving time ends or the time zone offset is decreased due to a time zone rule change), the returned List will have more than one element and will be sorted by ascending numerical value. When the input represents a local time skipped because of a positive time zone transition (e.g. when daylight saving time begins or the time zone offset is increased due to a time zone rule change), the returned List will be empty. Otherwise, the returned List will have one element.

And specified more precisely in UTC (which interprets its input as a number representing local time and returns a single milliseconds since epoch): https://arai-a.github.io/ecma262-compare/?pr=2781#sec-utc-t (emphasis mine)

If possibleInstants is not empty, then… Let disambiguatedInstant be possibleInstants[0]. [i.e., the chronologically first matching local time]
Else [a local time skipped at a positive time zone transition], … Let possibleInstants be GetNamedTimeZoneEpochNanoseconds [corresponding with] tBefore is the largest integral Number < t for which possibleInstants is not empty (i.e., tBefore represents the last local time before the transition) … Let disambiguatedInstant be the last element of possibleInstants
…
t is interpreted using the time zone offset before the transition

[ptomato]

I'm not sure there's really an effective test262 test possible for this; if I were to write one, it'd depend on implementation-defined date and time zone format strings. What else would be needed for merging this?

[michaelficarra]

@ptomato This does not require test262 tests to be merged. Waiting on 262 editor review.

[gibson042]

If a valid ECMA-262 implementation can return a UTC offset string from DefaultTimeZone, then ECMA-402 must not prohibit that (cf. API Overview: "This specification introduces new language values observable to ECMAScript code… and also refines the definition of some functions specified in ECMA-262 (as described below). Neither category prohibits behaviour that is otherwise permitted for values and interfaces defined in ECMA-262, in order to support adoption of this specification by any implementation of ECMA-262."). I believe this therefore affirms tc39/ecma402#683 .

[ptomato]

Concretely, should there be any change? Should we remove the paragraph starting "An ECMAScript implementation that includes the ECMA-402 ..." in anticipation of ECMA-402 no longer providing a definition for DefaultTimeZone?

(FWIW, I think ECMA-402's "A conforming implementation must recognize [...] Zone and Link names" makes it OK to also say that the return value of DefaultTimeZone must be one of them, but I see your point as well, so I don't see any reason to be strict about that.)

[gibson042]

I don't think anything needs to change here, I'm just calling attention to a downstream consequence. We can remove that text when there is no longer an override, but I think it should remain until then.

[ptomato]

Rebased; added the changes that Richard requested in a fixup commit.