Skip to content
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

Open
brycefisher opened this issue Aug 29, 2020 · 2 comments
Open

Best way to support chrono? #15

brycefisher opened this issue Aug 29, 2020 · 2 comments

Comments

@brycefisher
Copy link

I have a struct with a chrono::DateTime<Utc> value that I'd love to serialize/deserialize using this crate. Currently, I'm only using serde because of the easy integration with chrono. 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 between chrono and nanoserde in every project, I wonder if it would make more sense to add explicit support in this crate?

Thanks for this awesome crate!!

@brycefisher brycefisher changed the title Best way chrono support? Best way to get chrono support? Aug 29, 2020
@brycefisher brycefisher changed the title Best way to get chrono support? Best way to support chrono? Aug 29, 2020
@not-fl3
Copy link
Owner

not-fl3 commented Aug 29, 2020

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 :)

@brycefisher
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants