Serde integration feels wrong.

[quadrupleslap]

To a serde format, the chrono types are indistinguishable from string types. This works for JSON, because it doesn't have a proper date type, but for TOML and other formats with builtin date types it means strings can get deserialized into dates when actual dates can't. I'm not very familiar with serde, but it doesn't look possible for these formats to work around the fact that dates look indistinguishable from strings, other than also making their date types indistinguishable from strings, which feels wrong.

[quodlibetor]

Serde allows us to serialize and deserialize however we want, and it allows you to choose a serialization that you choose as well. I'm not sure what the best way to support multiple serialization formats with the same impl is, honestly.

If you just want to use a binary or otherwise alternate serialization there is an example custom deserialize for second-based timestamps inside of chrono, which looks like a lot but is mostly documentation.

Hm, I just realized that docs.rs doesn't include the serde feature when generating the docs, so I can't link to the recommended way of handling this pretty-printed for us, but we have docs, and it is really just a matter of implementing SerDe and using the with attribute.

The advantage of having the string format as the default is that it:

• round-trips with no information loss (timestamps lose tz info)
• is human readable

We also have the most common alternate representation as the ts_seconds module.

If you have other, commonly used, formats for datetimes I would be happy to take a PR for another ts_seconds-like module. (I'm probably going to implement a ts_millis module next time I need to, for example.)

I'm honestly not even sure what the correct write format would be for toml, since it's basically an unquoted string? Maybe just the string converted to ascii bytes so that it doesn't get the default quotes? It seems like it would require integration with the toml crate to get that right.