Normative: Allow non-402 implementations to support non-iso8601 calendars #2193
Conversation
gibson042
added
behavior
Codecov Report
@@ Coverage Diff @@
## main #2193 +/- ##
=======================================
Coverage 91.08% 91.08%
=======================================
Files 19 19
Lines 10558 10558
Branches 1695 1695
=======================================
Hits 9617 9617
Misses 931 931
Partials 10 10
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
spec/calendar.html
Outdated
| 1. Return « *"iso8601"* ». | ||
| </emu-alg> | ||
| <p> | ||
| This function returns a List of String values representing calendar types supported by the implementation. The contents of the List are implementation-defined, but must contain *"iso8601"* and must not contain any String value that does not identify a calendar type in the <a href="https://cldr.unicode.org/">Unicode Common Locale Data Repository (CLDR)</a>. |
There was a problem hiding this comment.
i like this! perhaps this could be represented as explicit algorithm steps doing these assertions, and then using the prose in the "return" step?
|
LGTM! |
|
Draft until presented to TC39 plenary. |
ptomato
force-pushed
the
gh-2192-allow-calendars-without-402
branch
from
8a3c47b
to
7a58b02
Compare
|
This achieved consensus at the June 2022 TC39 plenary meeting. |
This should have been part of #2193 but was forgotten. If a non-402 implementation is allowed to support more than just the iso8601 calendar, then it will need to have era/eraYear properties.
This should have been part of #2193 but was forgotten. If a non-402 implementation is allowed to support more than just the iso8601 calendar, then it will need to have era/eraYear properties.
Fixes #2192