Proposal-temporal: Double-check toLocaleString specs in a calendar world
A fair bit of work was done in early 2019 to add support for Temporal types to Intl.DateTimeFormat. We should do a second pass on this part of the spec now that we have calendar systems.
One small thing I noticed is that Temporal.Absolute should support the timeZoneName field, but that isn't listed in the table.
@ryzokuken
sffc
All 5 comments
@sffc sounds great, I'll review the spec.
ryzokuken
on 20 May 2020
@sffc right now, toLocaleString fails if the attached calendar isn't equal to _dateTimeFormat_.[[Calendar]] or ISO 8601. Is that an acceptable solution? If so, this issue can be closed.
ryzokuken
on 21 Oct 2020
@sffc right now,
toLocaleStringfails if the attached calendar isn't equal to_dateTimeFormat_.[[Calendar]]or ISO 8601. Is that an acceptable solution? If so, this issue can be closed.
This is the right behavior, as decided in #262.
The question to answer on this ticket is largely to make sure that all of the temporal types are correctly represented and handled in the Intl spec. For example, see #169 and open comments on #155.
sffc
on 21 Oct 2020
It looks like the spec is using iso internal slots without conversion to the relevant calendar; we should probably call all the getters that defer to the calendar instead.
Ms2ger
on 18 Nov 2020
Fixed by #1218, I think.
ptomato
on 3 Dec 2020
Related issues
justingrant
路
5Comments
thefliik
路
6Comments
romulocintra
路
6Comments
ryzokuken
路
3Comments
justingrant
路
4Comments
Most helpful comment
It looks like the spec is using iso internal slots without conversion to the relevant calendar; we should probably call all the getters that defer to the calendar instead.