Yeah, thought they were just gonna recommend the time crate (which has seen some modernization over the years).
Kind of unfortunate that the ecosystem is even more fragmented than I thought, but jiff is being developed by Andrew Gallant, who's on the Rust team, so that has the potential to become the new standard...
Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.
Coming from C not C++, I actually didn't like chrono at first, but grew to be okay with it, and it gets the job done.
I used chrono because it allowed storing a statically known timezone with 0 additional runtime bytes and had rkyv support. Both very important features for my application (rkyv database containing millions of timestamps).
I have yet to find a replacement library that supports either of these features.
rkyv is not like serde. There is no process of deserialization. The function rkyv::access(...) takes a &[u8], performs a consistency check, then casts the pointer it was passed to the desired type and returns Result<&T, Err>. I will say this again: "deserialization" in rkyv is a reference-to-reference conversion.
As you can imagine, it's very fast, but the tradeoffs are massive. The serialized bytes must exactly match the memory layout of a struct (usually distinct from the type being serialized) called the "archived type" (which must be #[repr(C)] or #[repr(transparent)], and which is most commonly generated from the fields of the struct being serialized using a derive macro). More importantly, there is nowhere to stick deserialization code which could convert a Unix timestamp to a jiff::Timestamp.
You can't really implement custom serialization schemes for third party types with it, at least not unless you want to define that #[repr(C)] struct yourself, and/or you're okay with actually deserializing (in rkyv, the Deserialize trait accepts a reference to the archived type and returns an owned value of the serialized type, usually by effectively cloning it) and the performance cost that entails, and with how my codebase is currently architected, I'd have to redo it every time I used the value. rkyv support kind of has to be baked into a library from the get-go for it to be worthwhile.
It has little to do with time on first glance, at least to me I read the name as a gif manipulation library. If it were named jiffy or similar it might be slightly more reasonable.
11 Comments
TheAgeOfSuperboredom@lemmy.ca · 13 pts · 25d
Wow! I always just used chrono out of familiarity. Guess I'll have to check out jiff!
trem@lemmy.blahaj.zone · 7 pts · 25d
Yeah, thought they were just gonna recommend the
timecrate (which has seen some modernization over the years).Kind of unfortunate that the ecosystem is even more fragmented than I thought, but
jiffis being developed by Andrew Gallant, who's on the Rust team, so that has the potential to become the new standard...BB_C@programming.dev · 5 pts · 25d
Nothing of significance will actually happen. The crate is too deeply intrenched in the ecosystem. And the little maintenance needed will be easily picked up.
Coming from C not C++, I actually didn't like
chronoat first, but grew to be okay with it, and it gets the job done.AVincentInSpace@pawb.social · 2 pts · 21d
sigh
I used chrono because it allowed storing a statically known timezone with 0 additional runtime bytes and had rkyv support. Both very important features for my application (rkyv database containing millions of timestamps).
I have yet to find a replacement library that supports either of these features.
BB_C@programming.dev · 2 pts · 21d
You can custom serialize
(timestamp, tz)ortimestamp, offsetor(timestamp, tz, offset), no?Ironically, that was a part of a back-and-forth I had with burntsushi (jiff dev) right here on lemmy.
AVincentInSpace@pawb.social · 1 pts · 20d
rkyv is not like serde. There is no process of deserialization. The function
rkyv::access(...)takes a&[u8], performs a consistency check, then casts the pointer it was passed to the desired type and returnsResult<&T, Err>. I will say this again: "deserialization" in rkyv is a reference-to-reference conversion.As you can imagine, it's very fast, but the tradeoffs are massive. The serialized bytes must exactly match the memory layout of a struct (usually distinct from the type being serialized) called the "archived type" (which must be
#[repr(C)]or#[repr(transparent)], and which is most commonly generated from the fields of the struct being serialized using a derive macro). More importantly, there is nowhere to stick deserialization code which could convert a Unix timestamp to ajiff::Timestamp.You can't really implement custom serialization schemes for third party types with it, at least not unless you want to define that
#[repr(C)]struct yourself, and/or you're okay with actually deserializing (in rkyv, the Deserialize trait accepts a reference to the archived type and returns an owned value of the serialized type, usually by effectively cloning it) and the performance cost that entails, and with how my codebase is currently architected, I'd have to redo it every time I used the value. rkyv support kind of has to be baked into a library from the get-go for it to be worthwhile.rtxn@lemmy.world · 0 pts · 25d
Rust developers come up with the worst fucking package names.
xav@programming.dev · 8 pts · 25d
Why ? It looks fine to my non-native-English eyes.
StripedMonkey@lemmy.zip · 5 pts · 24d
It has little to do with time on first glance, at least to me I read the name as a gif manipulation library. If it were named jiffy or similar it might be slightly more reasonable.
BB_C@programming.dev · 6 pts · 25d
Change your name to
Err::<!,!>(return).unwrap()sukhmel@programming.dev · 5 pts · 24d
Oh, they would
never