> For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339

A generic date type doesn’t come with any specific string format. ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type.

There’s also perfectly good solutions to those problems. Use a type alias to create a date type backed by a string, with formatting constraints (such as a regex). Then people can define dates using any string representation they want!

Incidentally this is exactly what Pkl lets you do. You can use Pkl schema to define in detail how you want to validate your data using various primitives like regex. And then separately create a config template that uses those custom data types. As a dev you can choose how tightly bound your config template is to a data validation schema, define all the validation in line, or import an external module to provide you with richly validated data types.

> ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type.

Tell that to the TOML authors [1].

It's good Pkl has string validation, but what if I don't want a string? What if I want my own literal datetime syntax, like TOML? The grammar for a configuration language could be made flexible enough to accept most anything as a value. In such a design the "string" type itself could be a regex rule defined by a schema.

Keep in mind datetime literals are just an example, the actual number of potential types is unbound.

[1] https://toml.io/en/v1.0.0#offset-date-time

This choice in TOML is a mixed bag. I would say it's substantially mitigated by the fact that strings must be quoted, so you don't have strings magically turning into datetimes if they look like a date. But it does add substantially complexity to an otherwise simple language.

The near-compatibility of ISO 8601 and RFC 3339 is a rich source of bugs, but that's hardly TOML's fault, and the standard is perfectly clear that the latter is used. TOML, like many configuration and data transport languages, is defined in terms of its syntax, so an abstract Date type doesn't make sense for it.

Providing a datetime format for TOML was probably the right decision, I think there are more people who complain about JSON lacking one than there are who complain about TOML having one.

Seems like someone should create a new datetime standard, documenting the safe intersection of ISO 8601 and RFC 3339. I did find this useful comparison: https://ijmacd.github.io/rfc3339-iso8601/

Even more reason to standardize the format used in configurations and to validate it early, rather than at runtime.