81
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 22 Jul 2024
81 points (100.0% liked)
Rust
6005 readers
3 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
If that's how it was framed in the comparison, it would have been fine. But my original objection was regarding the
Local
+FixedOffset
example which, IMVHO, toys, if ever so slightly, with disingenuity (no offense or aggression intended, I'm a fan).OK, fair enough. What should it say instead? Just omit the mention of
DateTime<Local>
? I used it because it's literally the only way toderive(Deserialize)
in Chrono in a way that gives you DST aware arithmetic on the result without getting time zone information via some out-of-band mechanism.Actually, I may have been too finicky about this myself.
Since I often write my own wrapping serialization code for use with non-serde formats, I didn't realize that
chrono::DateTime<chorono_tz::Tz>
wasn't serde-serializable, even with theserde
feature enabled for both crates. That's where the biggest problem probably lies.In the example, using
chorono_tz::Tz
, and only converting to-be-serialized values toFixedOffset
would probably put better focus on where the limitations/issues actually lie.OK, I've beefed that example up a little bit: https://github.com/BurntSushi/jiff/commit/08dfdde204c739e38147faf70b648e2d417d1c2e
I think the comparison is a bit more muddied now and probably worse overall to be honest. Maybe removing
DateTime<Local>
is the right thing to do. I'll think on it.It's a subtle comparison to make... Probably most people don't even realize that they're doing the wrong thing.