editor review: 402 independence

[ljharb]

from #1275 (comment):

https://tc39.es/proposal-temporal/#sec-temporal-systemtimezone depends on DefaultTimeZone, which is not an abstract operation in 262, but rather in 402. Temporal must work in the complete absence of 402.

[Ms2ger]

Presumably you mean DefaultTimeZone for the aop in 402, not SystemTimeZone.

One solution would be to move the 402 section "Time Zone Names" to 262; if you have thoughts on how to put that in the proposal, that would be helpful.

[ljharb]

whoops, yes, updated the OP.

[ljharb]

I'm not entirely sure what the best path is here - would all implementers be comfortable having the list of time zone names be mandatory, even when omitting 402?

[ptomato]

Another way to do it might be to treat "UTC" as the only time zone mentioned by name in 262, as we do with "iso8601" for calendars?

[ryzokuken]

@ptomato that sounds a good solution to me as well.

[ljharb]

It’s notable, though, that Date supports many timezones without 402 (presumably its implementation-defined; i haven’t checked yet), so it’d be good to word it so that impls don’t have to fully include 402 in order to offer multiple timezones.

[ptomato]

@ljharb I've made an attempt in #1305, I would like to get your opinion on that language.

[littledan]

It seems like we agree on the principle here (that 262-only implementations do not need to include the IANA tzdb) but we're debating how to codify it in #1305 . I think it's fine to iterate on the wording after Stage 3, before Stage 4, and that no fix to this needs to land before Stage 3 (though it would be fine to land if it's ready).

[ljharb]

I think it can only wait until stage 3 if we’re convinced it is possible to actually codify it in a useful way for non-402 engines. Additionally, until the separation is complete, editor review for stage 3 is more difficult.

[littledan]

@ljharb Sure, I'm having trouble understanding what the concern is. There's a lot of discussion in the PR thread about editorial details; could you be a little more clear on what your semantic concern is? For example, should we refrain from the requirement that non-402 engines can serialize the current timezone?

[ljharb]

My concern (which to be fair, is both as an editor and as a delegate) is that in the absence of 402, I want to ensure that Temporal does not have less usefulness than Date. Namely, that if Date conceptually supports my local time zone, then I think it's critical that Temporal be required to as well.

[littledan]

In #1305, everyone seems to be strongly agreeing that the local time zone and UTC must both be supported. We're iterating on editorial/formalistic details, but the normative requirements are agreed on. I believe this level of progress is what we need for Stage 3. (This isn't a memory model; the effort is just to get a pretty simple point across.)

[ljharb]

I would be content with a normative-ish placeholder note saying just that for stage 3, yes, and we can iterate on the exact text during stage 3.

[ptomato]

I realized we also have #519 open. Let's use that to discuss and make further changes.

[ljharb]

I don't think this is resolved - https://tc39.es/proposal-temporal/#sec-temporal.instant.prototype.tolocalestring, for example, includes "3. If the implementation does not include the ECMA-402 Internationalization API" but that's not how the spec handles this.

In other words, the AO in 262 needs to be complete in the absence of 402, and 402 replaces that AO with one that does the Intl thing.

[ptomato]

Oh, I see, I just missed rewriting that one to make it work like the others that I rewrote (cf. Temporal.PlainDate.prototype.toLocaleString). I'll change this.

[ljharb]

ah, guess i just got lucky and found the only one remaining :-p