> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.

I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString().

Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The problem is that sometimes you want a very specific format, not a locale-based format. This currently still has to be implemented in userland [1].

[1] https://github.com/js-temporal/proposal-temporal-v2/issues/5

A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them.

(If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)

I remember the first time I got in touch with Elixir and immutability as a core principle. It changed the way I wrote JavaScript since

The formatting decision is intentional and documented in the proposal: toString() is meant to be the round-trippable ISO representation, not a display string. For locale-aware output, toLocaleString() accepts the full Intl.DateTimeFormat options bag, which covers most real-world display needs.

For non-locale custom formats ("YYYY-MM-DD" style), there is a gap - Temporal deliberately does not ship a strftime-style templating system. The design rationale was that custom format strings are a source of i18n bugs (hard-coded separators, month/day order assumptions, etc). The idea was to push display formatting toward Intl so locale handling is correct by default.

In practice you can cover most cases with something like:

  const d = Temporal.PlainDate.from('2026-03-11')
  const parts = d.toLocaleString('en-CA', {year:'numeric',month:'2-digit',day:'2-digit'})

for YYYY-MM-DD (Canadian locale uses that order). Fragile, but workable.

The V2 issue Dragory linked is exactly tracking this - custom format pattern support is on the backlog. For now, date-fns or luxon work fine alongside Temporal if you need templated strings.