this post was submitted on 22 Jul 2024
80 points (97.6% liked)
Rust
5949 readers
5 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.