• BB_C@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    3 days ago

    You can custom serialize (timestamp, tz) or timestamp, offset or (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
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      3 days ago

      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.