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.
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.
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.
Wow! I always just used chrono out of familiarity. Guess I’ll have to check out jiff!
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…
jiff
Rust developers come up with the worst fucking package names.
Why ? It looks fine to my non-native-English eyes.
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.
Change your name to
Err::<!,!>(return).unwrap()Oh, they would
never
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.
