Rust

5974 readers

98 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]

11 comments fedilink hide all child comments

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

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

From COMPARE.md:

Conversely, in Jiff, all time zone lookups by name are cached.

Is the cache invalidated if system tzdata is updated?

And what effect does the answer have on the example from "Jiff supports detecting time zone offset conflicts" if both zoned datetimes used the system timezone which got updated between 1. opening 2. parsing the two zoned datetimes.

Jiff losslessly roundtrips time zone aware datetimes

In this section, wouldn't be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

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

In this section, wouldn't be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

They do say that the difference is that chrono users would need to keep out-of-band timezone information in addition to the datetime, whereas Jiff does it in-band.

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

That's fine. I didn't look at the code, but from what I gather, Jiff serializes the timezone name (not detailed tz info). chrono users would communicate the same thing, but it's not built-in functionality in the dt type itself.

The example I referred to however may imply that chrono users would be inclined do the wrong thing, and get the wrong result as a sequence.

(humble personal opinion bit) It feels like it's a case where the example was pushed a bit extra to fit into the "jump into the pit of success/despair" reference. A reference many, young and old, wouldn't recognize, or otherwise wouldn't care for anyway.

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

You should look at it, they say the implement RFC 9556 timestamps, which include tz info. In my experience it IS useful in real use, because a fixed offset timestamp can lose a bit of information.

For example, if you have a timestamp and want to add a few months to it, for example for a reminder, you will get a timestamp at the same time in the same offset. In many cases that will be wrong, because of things like daylight savings time, which change the offset of the timezone. You will get a timestamp an hour before or after the moment you intended, and it will be in the "wrong" offset in that timezone in that time of year. With timezone aware timestamps, they are aware that the offset will change, and will be able to give a timestamp in the future at the correct time and offset.