Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make list of supported calendars #395

Closed
sffc opened this issue Dec 11, 2019 · 5 comments
Closed

Make list of supported calendars #395

sffc opened this issue Dec 11, 2019 · 5 comments
Assignees
Labels
c: spec Component: spec editorial issues editorial Involves an editorial fix s: help wanted Status: help wanted; needs proposal champion Small Smaller change solvable in a Pull Request
Milestone

Comments

@sffc
Copy link
Contributor

sffc commented Dec 11, 2019

In Section 6 of the spec, we have well-defined rules for supported locales, currencies, and time zones, and Unified NumberFormat is adding a specific list of supported units.

I think we need to also add a list of supported calendars. We are increasingly using calendars throughout Intl APIs, and we will also be using them in Temporal.

@pipobscure

@pipobscure
Copy link

I think that's a good idea.

@littledan
Copy link
Member

Just for background, why supported calendars when we don't have supported locales (and we're pretty set on not adding that)?

@sffc
Copy link
Contributor Author

sffc commented Dec 11, 2019

why supported calendars when we don't have supported locales

Good question.

Locales are used only for output. Programmers should generally not use the result of .format operations for any other purpose. However, with calendars being supported in Temporal, which provides more sophisticated operations, I think programmers reasonably have a higher expectation for knowing which ones they can safely use on their website.

For example, if a website targeting Chinese users wanted to do date math specifically in the traditional Chinese calendar, they would have to test whether their date math works in all browsers.

An alternative could be for Temporal to have its own set of supported calendars, but let Intl.DateTimeFormat implement its own. However, I think this is not a good idea, because I think programmers should have the expectation that the following command always works without throwing a RangeError:

Temporal.now.date().withCalendar(Intl.defaultCalendar)

We can brush that issue under the rug by vague spec language that says that any calendar supported for display in Intl.DateTimeFormat must also be supported for calculations by Temporal. But then we get back to the first issue of programmers not knowing which explicit calendars are supported.

@sffc sffc added c: meta Component: intl-wide issues s: discuss Status: TG2 must discuss to move forward labels Dec 11, 2019
@sffc
Copy link
Contributor Author

sffc commented Feb 26, 2020

Discussion from ECMA-402 meeting: https://github.com/tc39/ecma402/blob/master/meetings/notes-2020-01-09.md#issue-make-list-of-supported-calendars. Key points:

  • DE: We have required numbering systems. It does seem like a fatal error if someone counts on a particular locale to be present but it is not.
  • LHO: From a polyfill perspective, this would be difficult, to have a list of mandatory calendars, because there is more to do.

We therefore did not reach a conclusion. Therefore, I want to propose that we simply add the following requirement: "any calendar that is supported for formatting must also be supported for Temporal". This can be part of the Intl Temporal effort.

@sffc sffc added s: comment Status: more info is needed to move forward and removed s: discuss Status: TG2 must discuss to move forward labels Feb 26, 2020
@sffc sffc added s: discuss Status: TG2 must discuss to move forward and removed s: comment Status: more info is needed to move forward labels Jun 5, 2020
@sffc sffc added this to the ES 2021 milestone Jun 5, 2020
@sffc sffc added the Small Smaller change solvable in a Pull Request label Jun 5, 2020
@sffc sffc added s: comment Status: more info is needed to move forward and removed s: discuss Status: TG2 must discuss to move forward labels Jul 8, 2020
@sffc sffc removed this from the ES 2021 milestone Jul 8, 2020
@sffc sffc added this to the ES 2022 milestone Apr 18, 2021
@sffc sffc added s: help wanted Status: help wanted; needs proposal champion c: spec Component: spec editorial issues editorial Involves an editorial fix and removed s: comment Status: more info is needed to move forward c: meta Component: intl-wide issues labels Apr 18, 2021
@sffc
Copy link
Contributor Author

sffc commented May 2, 2024

I believe this is fixed:

https://tc39.es/proposal-temporal/#sec-calendar-types says that Temporal should support exactly the same set of built-in calendars as ECMA-402

Intl Enumeration API gives an iterator over those calendar types.

@sffc sffc closed this as completed May 2, 2024
@sffc sffc assigned sffc and unassigned ryzokuken May 2, 2024
@sffc sffc moved this to Priority Issues in ECMA-402 Meeting Topics Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: spec Component: spec editorial issues editorial Involves an editorial fix s: help wanted Status: help wanted; needs proposal champion Small Smaller change solvable in a Pull Request
Projects
Archived in project
Development

No branches or pull requests

4 participants