TC39 ECMA402
2023-02-01
plaintext logs
prev next
source on github
00:21
<sffc>
Hmm, I may be open to considering if DTF *always* throws on ZDT, or perhaps any Temporal object, if the time zone is not undefined, because if you're using Temporal, you shouldn't get your time zone from Intl
01:37
<justingrant>

There are three cases:

  • Instant - time zone is unknown, so no potential for conflict. Instant has the same data model as Date, so they should behave identically in format.
  • ZonedDateTime - time zone is known, so there's potential for conflict. This is the focus of the PR linked above.
  • Plain* types - time zone is excluded from the data model, so currently the 402 section of the Temporal spec doesn't include the [[timeZoneName]] in the list of supported fields. We could discuss changing this behavior, but IMO this should be a separate PR and discussion.

So the issue at hand is really focused on how to handle ZonedDateTime output only.

01:42
<sffc>
Right. Yeah. So it seems reasonable that Instant always converts to the time zone if the DTF, and ZDT always retains its time zone
01:43
<justingrant>
Hmm, I may be open to considering if DTF *always* throws on ZDT, or perhaps any Temporal object, if the time zone is not undefined, because if you're using Temporal, you shouldn't get your time zone from Intl

My main concern is ensuring that, if there's no timeZone option specified on the Intl side, then the output of format includes the ZDT's time zone.

What we do if there's also a timeZone option on the Intl side is a much lower priority because it seems like it'll be a pretty rare use case. I'm not strongly opposed to your suggestion to always throw in that case, but I'd like to understand your reasoning for why we'd deviate from calendar behavior where both are allowed as long as they don't conflict.

01:43
<sffc>
The only thing I'm unsure about are the implications for data loading. With this model, the DTF needs to be able to select the time zone in the format function, which means all the display names for all time zones need to be available and efficiently indexable
01:44
<sffc>
Currently, the DTF can do the time zone name lookup in the constructor, which is likely more efficient
01:49
<justingrant>
Is there any choice but to solve this perf problem? Otherwise, zonedDateTime.toLocaleString() would return the system time zone which is never what's intended.
01:49
<sffc>
I'm not sure if that's a real concern; Frank could weigh in. A workaround would be that the time zone must match, a restriction we could later lift. This is fine in toLocaleString.
01:50
<sffc>
I definitely think that DTF converting ZDT to a different time zone is a bad idea, just like converting to a different calendar is a bad idea
01:52
<sffc>
So I guess the options are (1) always use ZDT zone and eat the format-time lookup cost; (2) require the time zones to match; or (3) require the time zones to match but only if the constructor received an explicit zone.
01:53
<justingrant>

I'm not sure if that's a real concern; Frank could weigh in.

Even if it's a real concern, doesn't that concern have to be solved in order to implement an efficient parameterless toLocaleString?

01:54
<ptomato>
no, because toLocaleString would have no choice but to construct the DTF instance, so that cost is incurred in toLocaleString either way
01:54
<sffc>
If we did (2) we could switch to (1) or (3) later since they are less strict
01:54
<ptomato>
in other words, if you want efficient toLocaleString, you create a DTF and call format instead 😄
01:56
<sffc>
But I think we should decide on the issue ptomato raised in Intl about whether to resolve the undefined time zone at construction or formating time, because that decision could lead to different value judgements here
01:57
<sffc>
Like, if DTF responds to browser time zone changes, it means it must retain access to time zone data even after it is constructed
02:05
<justingrant>
AFAICT, in the current spec, toLocaleString doesn't work either. At a minimum could we get consensus on fixing that method now, even if the DTF side of things is still an open question?
02:08
<justingrant>
BTW, the polyfill doesn't match the spec today. In the polyfill, ZDT.p.toLocaleString outputs the ZDT's time zone name.
02:10
<justingrant>
In the current spec, it just passes locales and options directly down to the internal DTF constructor.
02:16
<justingrant>
Here's the current spec: https://tc39.es/proposal-temporal/#sup-temporal.zoneddatetime.prototype.tolocalestring
02:16
<justingrant>
1. Let zonedDateTime be the this value.
2. Perform ? RequireInternalSlot(zonedDateTime, [[InitializedTemporalZonedDateTime]]).
3. Let dateFormat be ? Construct(%DateTimeFormat%, « locales, options »).
4. Return ? FormatDateTime(dateFormat, zonedDateTime).