Miss Dada  🏳️‍⚧️

I'm reading RFC 3339 in preparation to defend my position and I just read the most incredible sentence. I've copied it below:https://twitter.com/myrrlyn/status/1215034347146727424 …

I absolutely agree that this is the format that should be used to transmit dates and times over the internet. You should not require that complexity to parse a markup language in its most basic form. The edge cases for dealing with gregorian dates are mind boggling

personally, I wobble between whether the grammar should merely /tokenize/ a stamp (it matches the syntactical layout) or /parse/ it (the described moment exists in the UTC sequence)

Either way every datetime library already ships with a production grade iso-8601 parser, by doing this you're forcing them to also handle whatever niche type your library ships to represent this.

as with unicode handling, this seems like something that the config library should delegate to the datetime library, and not vice versa though the toml crate has its own type instead of using core::time or chrono, which I should investigate rather than continue Posting

It's much easier to delegate to the datetime library when you don't make datetime a dedicated type in the format :) I don't think the comparison to unicode is fair, since the decoder fundamentally has to care about strings to parse its input

I meant to bring up Unicode only in the sense that the grammar is not required to know information about the meaning of the text (parsing a stream of char is obviously Way Too Much Abstraction; requiring UTF-8 or a bad encoding is ok), only its shape, and delegate to specialists

but my abstract position is that nobody blinks at the fact that parsing a 754 literal correctly requires a detailed format and behavior specification, and 754 literals don't need to be wrapped as opaque text for a config lang. we can lift other complex literals to that level also