I assume that options like timeZone, calendar, and fractionalSecondDigitswill be supported because they affect the non-localized numeric values of the output. If this assumption is wrong, please explain why. Thanks!
That sounds reasonable. I'm not very familiar with other calendars than Gregorian; do others also have standardised ways of displaying dates?
After thinking about it, I'm not sure that supporting the calendar option would be a good idea or not.
Although each CLDR calendar has a year, month, and day for every ISO date, the ISO 8601 format (at least in Temporal) implies the ISO calendar too. So in Temporal, the output of a chinese date's toString isn't YYYY-MM-DD using chinese year,month/day vaues. Instead it's YYYY-MM-DD[u-ca=chinese]. This might create ambiguity about what a non-ISO-calendar's YYYY-MM-DD output represents.
That said, existing code might be using formatToParts to extract non-ISO-calendar year, month, and day. This might argue for accepting a calendar option.
So it's a bit of a quandry: using calendar in format is problematic for Temporal alignment reasons, while not using it in formatToParts is problematic for backwards-compatibility reasons. (Where "backwards compatibility" means that users can switch their existing code that uses a locale like en-US with formatToParts without breaking that code.)
From https://github.com/eemeli/proposal-intl-root-locale/issues/2#issuecomment-1703762707:
After thinking about it, I'm not sure that supporting the calendar option would be a good idea or not.
Although each CLDR calendar has a year, month, and day for every ISO date, the ISO 8601 format (at least in Temporal) implies the ISO calendar too. So in Temporal, the output of a chinese date's
toStringisn't YYYY-MM-DD using chinese year,month/day vaues. Instead it'sYYYY-MM-DD[u-ca=chinese]. This might create ambiguity about what a non-ISO-calendar's YYYY-MM-DD output represents.That said, existing code might be using
formatToPartsto extract non-ISO-calendar year, month, and day. This might argue for accepting acalendaroption.So it's a bit of a quandry: using
calendarinformatis problematic for Temporal alignment reasons, while not using it informatToPartsis problematic for backwards-compatibility reasons. (Where "backwards compatibility" means that users can switch their existing code that uses a locale likeen-USwithformatToPartswithout breaking that code.)