[zbraniecki]

`strftime` is not an internationalization API! It's a datetime formatting API! :)

I can see an appeal for it, and I wouldn't mind `Date` or `Temporal` to have such pattern-driven formatting, but it is critical to recognize that it is not internationalization and thus doesn't belong there.

In particular, if you use `strftime` like formatting you're doing the opposite - you're hardcoding the formatting into a single pattern. It may be the right thing for your project, but it definitely is not i18n :)

[csande17]

In practice, though, to implement Intl you pretty much need a robust implementation of a strftime-like date formatting function, as well as a full set of month/weekday/etc strings for every language you support. So it's less "add this functionality" and more "expose the functionality this clearly already has".

[zbraniecki]

You're correct. Intl formatting has two components: - Selecting the appropriate pattern for a given locale - Formatting numbers and words into the given locale (example: eastern-arabic numerals and Arabic month/week names).

You might say "I want to supply my own pattern, you just do step two for me" and technically we can provide that functionality by exposing it.

The issue is that from the API design perspective it would lead to people misusing the API misunderstanding what is going on and believing that they "internationalized their UI" which is not the case. In fact, they'd make things worse for their users than if they just displayed a date in a single locale with consistent pattern+localization because in some cases "MM/DD" and "DD/MM" are indistinguishable when expanded and that may lead to data loss, security loss, or just confusion.

I'd argue that every case where you want to supply your own pattern is a case where you should not attempt to internationalize that pattern. I also recognize that it's just my opinion.