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

    Time zone transition changes happen all the time. Once you start storing datetimes in the future, you’re in a bit of a precarious position here. Moreover, this is a standardized interchange format that other libraries will know how to read/write. (It’s relatively newly standardized, but has been used in practice among other datetime libraries.)

    I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?

    The point is almost never about “it is literally impossible to accomplish task foo,” but rather, it matters how it’s approach and how easy it is to do. And if you have to rely on your users having very specific domain knowledge about this, it’s likely there will be errors. As my design docs state, I didn’t only make Jiff to offer more functionality. I also made it because I felt like the APIs could be better. That’s a very subjective valuation, and I find arguments of the type, “well I can just use the old library in this way as long as I hold it right and it actually works just fine” to be missing the forest for the trees.

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

      I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?

      Something like this?

      It can support tzfile too around the wire if it starts to expose tz names in a future version.

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

        Again, to be clear, I’m not saying it’s impossible to do. But in order to do it, you have to build your own abstractions. And even then, you still can’t do it because tzfile doesn’t give you enough to do it. And tzfile has a platform specific API with no caching, so every time you parse a datetime with a tz ID in it, it’s completely reloading the TZif data from disk.

        Some of these things are implementation quality issues that can be fixed. Others are library design problems where you can achieve your objective by building your own abstractions. 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. And that mentioning this is appropriate in the context of the “facts of comparison” because it translates into a real user experience difference for callers.

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