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

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

    • burntsushi@programming.devOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      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.

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

        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.