3 ms·
> 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
by hgs3 3y ago
> 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 https://toml.io/en/v1.0.0#offset-date-time
- samatman 3y agoThis 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.