How to handle thecalendar option in this proposal's Intl.DTF?

[justingrant]

From #2 (comment):

I assume that options like timeZone, calendar, and fractionalSecondDigits will 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.)