Serialization/deserialization does not round trip

[sbditto85]

Right now I can serialize a DateTime<Tz>, but I cannot Deserialize it.

serde_json::to_string(&local_time);

produces "2020-05-01T04:45:00MDT"

but

let undo: DateTime<chrono_tz::Tz> =
                serde_json::from_str("\"2020-05-01T04:45:00MDT\"").expect("it all to work");

gives a compile error

error[E0277]: the trait bound `chrono::datetime::DateTime<chrono_tz::timezones::Tz>: serde::Deserialize<'_>` is not satisfied
    --> src/lib.rs:670:17
     |
670  |                 serde_json::from_str("\"2020-05-01T04:45:00MDT\"").expect("it all to work");
     |                 ^^^^^^^^^^^^^^^^^^^^ the trait `serde::Deserialize<'_>` is not implemented for `chrono::datetime::DateTime<chrono_tz::timezones::Tz>`
     | 
    ::: /root/.cargo/registry/src/github.com-1ecc6299db9ec823/serde_json-1.0.45/src/de.rs:2375:8
     |
2375 |     T: de::Deserialize<'a>,
     |        ------------------- required by this bound in `serde_json::de::from_str`
     |
     = help: the following implementations were found:
               <chrono::datetime::DateTime<chrono::offset::fixed::FixedOffset> as serde::Deserialize<'de>>
               <chrono::datetime::DateTime<chrono::offset::local::Local> as serde::Deserialize<'de>>
               <chrono::datetime::DateTime<chrono::offset::utc::Utc> as serde::Deserialize<'de>>

Is there any way for me to keep the Tz information when passing from server to frontend(WASM) in one value? or do I have to pass the Tz separate with a NaiveDateTime?

[quodlibetor]

In general it's probably a bad idea to serialize anything other than UTC times, as the actual "true" time can change when local governments change their DSTs or make arbitrary adjustments.

So, yes, you should only ever serialize Utc and a separate timezone.

That said, this should roundtrip and I'd consider this a bug. I'd be happy to take a PR that changes the serialization of timezones to the full name. Tz deserialization may still fail if the tz database is different on the computer deserializing the dt, but at least it will be possible.

[quodlibetor]

Related to #44

[doivosevic]

I'll ask here since this is the only deserialization issue I found related to chrono_tz. Is there a reason why Tz cannot be deserialized? It's all Continent/City combinations. Is there a reason why this wouldn't work?

[doivosevic]

It would be really nice if we could get this. I would like to serialize/deserialize just for some testing fixtures and missing this complicates things a lot

[allan2]

I'll ask here since this is the only deserialization issue I found related to chrono_tz. Is there a reason why Tz cannot be deserialized? It's all Continent/City combinations. Is there a reason why this wouldn't work?

chrono_tz::Tz is Serialize and Deserialize. You just have to enable the serde feature for chrono-tz.

[doivosevic]

Could you point me to the feature? I don't see it listed here https://github.com/chronotope/chrono-tz/blob/main/chrono-tz/Cargo.toml

[djc]

It is an implicit feature from the optional dependency.

[calvcoll]

I've come across this issue in particular a couple of times when trying to figure out a solution just to check I wasn't confused.

I assume the issue of DateTime<Tz> deserialisation won't happen via chrono-tz, due to this error wheen trying to specify impl Deserialize for DateTime<Tz>. Any implementation of Deserialization would, I assume, have to be implemented on the parent crate with an optional dependency on chrono-tz.

Do we know if the chrono team would likely be interested in a patch that does that? As it seems to tie to one timezone library (even if it only compiles/is a feature if chrono-tz was found as a dependency).

[calvcoll]

Just realised, that's a really dumb idea from me as it'd create a circular dependency 🤦