-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Best way to support chrono? #15
Comments
Hi! Take a look on the example of using proxy: https://gist.github.com/not-fl3/f40d2025542ef9a4b8c76896343171dc For chrono's datatypes it would be quite similar I believe: you will need to create your own struct with all the fields you want to serialize (like hours/minutes etc) and implement Into and From for chrono's Date. I am not sure that it is worth adding to the core library though: there are plenty of third party crates on crates.io and we will eventually end up with tons of dependencies on everything to support all the crates out of the box. Let's keep this issue open though, I did not yet thought properly on this and maybe someone else will have some opinions :) |
Thanks so much for providing a proxy example and for thinking hard about this use case! Figuring out where to draw the line between built-in and not built-in support for 3rd party types could easily become a slippery slope. I happen to think date types is a pretty common use case, but I don't have to support this library into perpetuity. Here's a nice middle ground that jonhoo and I came up with for a similar case in another crate: an example that's tested in CI. |
I have a struct with a
chrono::DateTime<Utc>
value that I'd love to serialize/deserialize using this crate. Currently, I'm only usingserde
because of the easy integration withchrono
. I think I could somehow do this using a proxy, but I'm not quite sure how to do that.My feeling is that
chrono
is the winner for datetime operations in the ecosystem. Rather than reimplementing glue code betweenchrono
andnanoserde
in every project, I wonder if it would make more sense to add explicit support in this crate?Thanks for this awesome crate!!
The text was updated successfully, but these errors were encountered: