78
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
78 points (97.6% liked)
Rust
5754 readers
40 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+FixedOffsetexample 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 theserdefeature 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 toFixedOffsetwould 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.