Support something useful for timestamps on stable

[sgrif]

Rust's Timespec isn't stable. We should optionally support chrono.

[tomhoule]

Well, I have been playing a little with diesel and I wrote a rough port of the rust-postgres support for chrono::DateTime using a wrapper struct to implement the Expression, FromSql<Timestamp> and ToSql<Timestamp> traits. The code seems to work (my tests are not very thorough, and I haven’t checked if it works well for building queries yet, just (de)serialization) for the very limited case it covers.

It assumes everything is UTC and does not try to deal with timezones at the moment, but it should be possible at least to the same extent as what exists in rust-postgres.

The rust-postgres implementation of the feature is in this file

If it can be of any help, I can share, expand, complete and polish up the code, write tests and make a PR.

[sgrif]

Sure. If you want to open a PR with what you have, I can do the legwork on finishing it up, too.

[sgrif]

Also I think the only tests that we need for this are an entry in https://github.com/sgrif/diesel/blob/master/diesel_tests/tests/types_roundtrip.rs#L76

It is a shame that we need this in diesel proper -- I really wish that we could make diesel-chrono be a separate crate.

[tomhoule]

I worked a little on this, I doubt it is fully functional, but I’ll open a PR right away so you can see if it is worth continuing.

My first implementation was in application code, but of course I had to wrap it in a newtype, and write down the serde traits for serialization, etc. So that was not particularly ergonomic.

[sgrif]

Yeah, that's the main benefit of doing it in crate is not needing to newtype it.

[sgrif]

The only remaining type for this is chrono::NaiveDate. A close to working implementation was done in c0b0fb8 but it was ultimately reverted as I treated 0 as the start of the Julian era, when PG treats it as the start of the PG epoch. Anyone interested should feel free to adapt that code, with tests similar to what have been added to the other date/time types w/ concrete values added for NaiveDate to prove that it's correct.

#106 has been added as a separate tracking issue for figuring out how we should handle timezone aware types.

[sgrif]

Fixed by #114, #101, and #94