The whole business with the syntax typing has no "one correct way" to do it. No matter what you do it will cause problems and headaches for someone at some point somewhere.
> Dates and times, as many more experienced programmers are probably aware is an unexpectedly deep rabbit hole of complications and quirky, unexpected, headache and bug inducing edge cases. TOML experiences many of these edge cases because of this.
Eh? In the original text it links to three issues to back this up:
That first issue it links to is "failed to parse long floats like x = 0.1234567891234567891" and the third is a feature request for hex values (v = 0xff, not even a bug report). That has nothing to do with dates? The second issue did relate to dates, but was just a simple bug, not an "unexpectedly deep rabbit hole of complications and quirky, unexpected, headache and bug inducing edge cases".
This just seems repeating a tautology. I maintain a TOML implementation that sees some reasonable use. Dates have not been a huge source of bugs, confusion, or other issues. All you need is to be able to parse RFC 3339 style dates (and some things derived from that), which is usually just calling strftime() or whatever your language has for this.
I do think TOML had some bits I wouldn't have added (not dates though), but the feature sets and complexity of TOML and YAML and not even comparable; it's like comparing Iceland (pop: ~300k) to Ireland (pop: ~5M). Yes, they're both islands and both are small countries, yet the scale of their "smallness" is just completely different.
This might convince me to start using TOML. I hate JSON for configs (not all parsers support comments, yes I know JSON5 exists), and TOML's table syntax really sucks. YAML has its flaws, but it fits the bill the best IME.
Now I just have to hope enough TOML tools support this syntax, lest I end up in the same boat as JSON5.
What's the difference with JSON in that example? No double quotes around keys, that seems to be about it. It seems more practical/readable than JSON if you have very limited need for nesting, but the old format would suffice then too.
In that specific example not too much, but obviously there's a whole bunch of differences between TOML and JSON, starting with the fact that you can add comments as has already been discussed, and many more.
Given how many comment remover util functions I have written to make almost JSON config files proper JSON ... why could they not just have included those in the spec.
Because JSON is not designed for configuration files, but for data interchange, and this makes JSON "better" for that use case (the original motivation was "people were adding comment-based pragmas to JSON files, so I removed comments", but without comments it's also easier to parse, concatenate, etc.)
But the whitespace handling involved is an extra complication, at least the provided example fails to be parsed by `tomli`, which is following the currently release TOML spec: https://github.com/hukkin/tomli/issues/199
> Dates and times, as many more experienced programmers are probably aware is an unexpectedly deep rabbit hole of complications and quirky, unexpected, headache and bug inducing edge cases. TOML experiences many of these edge cases because of this.
Eh? In the original text it links to three issues to back this up:
That first issue it links to is "failed to parse long floats like x = 0.1234567891234567891" and the third is a feature request for hex values (v = 0xff, not even a bug report). That has nothing to do with dates? The second issue did relate to dates, but was just a simple bug, not an "unexpectedly deep rabbit hole of complications and quirky, unexpected, headache and bug inducing edge cases".
This just seems repeating a tautology. I maintain a TOML implementation that sees some reasonable use. Dates have not been a huge source of bugs, confusion, or other issues. All you need is to be able to parse RFC 3339 style dates (and some things derived from that), which is usually just calling strftime() or whatever your language has for this.
I do think TOML had some bits I wouldn't have added (not dates though), but the feature sets and complexity of TOML and YAML and not even comparable; it's like comparing Iceland (pop: ~300k) to Ireland (pop: ~5M). Yes, they're both islands and both are small countries, yet the scale of their "smallness" is just completely different.