Eemeli Aro

Based on RFC3339, the regexp would be a bit simpler: ``` [0-9]{4} -(0[1-9]|1[0-2]) -(0[1-9]|[12][0-9]|3[01]) (T([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)? (Z|[+-]([01][0-9]|2[0-3]):[0-5][0-9])?)? ``` If we wanted to hedge our bets, this is the subset that's valid...

As pointed out by @hsivonen during the ECMA-402 call, the HTML spec [provides](https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#dates-and-times) another reasonable ISO 8601 subset for us to depend on. That one supports 4+ digit years >...

To rephrase my general viewpoint here, I would like us to arrive at _some_ solution where a valid JS implementation can use _either_ `new Date(input)` or once Temporal lands, `Temporal.Instant.from(input)`,...

That's why the custom regexp in #687, because anything matching that _should_ work everywhere, as long as it doesn't use a non-existent day like 2024-02-31.

The datetime functions are still in draft for 48.

@sffc Could you share a couple of examples of what a semantic skeleton value could look like when used as an MF2 option value? It's not immediately obvious to me...

Thus far, the option sets for `:number` and `:datetime` have been kept as subsets of the options available in the JS `Intl` formatters. Departing from that approach is something that...

This direction was chosen in #1083.

That's an interesting point. The change I'm proposing here would effectively make some current data model errors unrepresentable in the data model. An MF2 syntax message could still contain such...

The additional information is encoded within the declaration expressions. At its simplest, a message like ``` .input {$foo} .local $bar = {$foo} {{...}} ``` could be represented as: ```js {...