Rust

5942 readers

2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

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

[email protected]

Jiff is a new date-time library for Rust that encourages you to jump into the pit of success (github.com)

submitted 3 months ago by [email protected] to c/[email protected]

27 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 3 months ago* (last edited 3 months ago) (1 children)

Again, to be clear, I'm not saying it's impossible to do. But in order to do it, you have to build your own abstractions. And even then, you still can't do it because tzfile doesn't give you enough to do it. And tzfile has a platform specific API with no caching, so every time you parse a datetime with a tz ID in it, it's completely reloading the TZif data from disk.

Some of these things are implementation quality issues that can be fixed. Others are library design problems where you can achieve your objective by building your own abstractions. Like do you really not see this as something that shouldn't be mentioned in a comparison between these crates? You must recognize the difference between what you're doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you. And that mentioning this is appropriate in the context of the "facts of comparison" because it translates into a real user experience difference for callers.

[–] [email protected] 1 points 3 months ago (1 children)

Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you.

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

[–] [email protected] 1 points 3 months ago (1 children)

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 to derive(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.

[–] [email protected] 1 points 3 months ago (1 children)

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 the serde 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 to FixedOffset would probably put better focus on where the limitations/issues actually lie.

[–] [email protected] 2 points 3 months ago

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.