Summary of discussion from tc39/proposal-temporal#796:

When working with legacy or third-party systems, you often find yourself receiving date strings in the most unwieldy formats. To remedy this, date libraries often support custom format strings to make it possible to parse such strings.

A Temporal.(type).fromFormat(string, formatString) method was proposed. This format from Unicode TR 35 was identified as a likely microformat to use. It's also used by date-fns with a few additions.

This was the most popular feature that didn't make it into the original Temporal proposal, as determined unscientifically by GitHub emoji reactions and number of times it was mentioned in our feedback survey.

Advantages:

Parsing is difficult to do correctly, and possibly out of reach entirely for inexperienced developers. This is one of the reasons developers have turned to third-party libraries instead of using legacy Date.

Parsing textual month names or era names in a locale-aware way would require including a large bundle of locale data, defeating the purpose of using Temporal rather than Moment or another locale-aware library.

Concerns:

The philosophy in the original Temporal proposal was that parsing anything other than ISO strings is in the domain of business logic because everybody knows their own use case better than Temporal can.

Whatever is enabled here should not repeat the mistakes of Date.parse().

Prior art:

• Moment.js supports passing a format string as a second argument: moment("07-28-2020", "MM-DD-YYYY")
• Luxon also supports this through its .fromFormat() method: DateTime.fromFormat("07-28-2020", "MM-DD-YYYY")
• date-fns: parse('07/28/2020', 'MM/dd/y', new Date())
• Java's DateTimeFormatter is an entity you construct with your pattern ('YYYY-MM-DD' etc), and use for both parsing and printing/formatting.

Constraints / corner cases:

• Temporal.PlainDate.fromFormat('2021-02-11', 'yyyy-MM') — format string doesn't include all the required fields
• Temporal.PlainDate.fromFormat('2021-13-11', 'yyyy-MM-dd') — month is invalid in the ISO calendar but could be valid in another calendar. Need a way to indicate in which calendar the string is parsed.