• BB_C@programming.dev
    link
    fedilink
    arrow-up
    8
    ·
    5 months ago

    From COMPARE.md:

    Conversely, in Jiff, all time zone lookups by name are cached.

    Is the cache invalidated if system tzdata is updated?

    And what effect does the answer have on the example from “Jiff supports detecting time zone offset conflicts” if both zoned datetimes used the system timezone which got updated between 1. opening 2. parsing the two zoned datetimes.

    Jiff losslessly roundtrips time zone aware datetimes

    In this section, wouldn’t be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

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

      Is the cache invalidated if system tzdata is updated?

      Yes, although at present, there is a TTL. So an update may take “time” to propagate. jiff::tz::db().reset() will force the cache to be invalidated. I expect the cache invalidation logic to get tweaked as we get real experience with it.

      And what effect does the answer have on the example from “Jiff supports detecting time zone offset conflicts” if both zoned datetimes used the system timezone which got updated between 1. opening 2. parsing the two zoned datetimes.

      It’s hard to know precisely what you mean. But once you get a jiff::tz::TimeZone, that value is immutable: https://docs.rs/jiff/latest/jiff/tz/struct.TimeZone.html#a-timezone-is-immutable

      New updates to tzdb are only observed when you do a tzdb lookup.

      In this section, wouldn’t be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

      That’s kinda my point. How do they do that? And does it work with chrono-tz and tzfile? And what happens if tzdb updates lead to a serialized datetime with an incorrect offset in a future update of tzdb? There are all sorts of points of failure here that Jiff will handle for you by virtue of tighter integration with tzdb as a first class concept.

    • Yoddel_Hickory@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      5 months ago

      In this section, wouldn’t be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

      They do say that the difference is that chrono users would need to keep out-of-band timezone information in addition to the datetime, whereas Jiff does it in-band.

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

        That’s fine. I didn’t look at the code, but from what I gather, Jiff serializes the timezone name (not detailed tz info). chrono users would communicate the same thing, but it’s not built-in functionality in the dt type itself.

        The example I referred to however may imply that chrono users would be inclined do the wrong thing, and get the wrong result as a sequence.

        (humble personal opinion bit) It feels like it’s a case where the example was pushed a bit extra to fit into the “jump into the pit of success/despair” reference. A reference many, young and old, wouldn’t recognize, or otherwise wouldn’t care for anyway.

        • Yoddel_Hickory@lemmy.ca
          link
          fedilink
          arrow-up
          2
          ·
          5 months ago

          You should look at it, they say the implement RFC 9556 timestamps, which include tz info. In my experience it IS useful in real use, because a fixed offset timestamp can lose a bit of information.

          For example, if you have a timestamp and want to add a few months to it, for example for a reminder, you will get a timestamp at the same time in the same offset. In many cases that will be wrong, because of things like daylight savings time, which change the offset of the timezone. You will get a timestamp an hour before or after the moment you intended, and it will be in the “wrong” offset in that timezone in that time of year. With timezone aware timestamps, they are aware that the offset will change, and will be able to give a timestamp in the future at the correct time and offset.

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

            I think you misunderstood me.

            What I meant is, someone who wants to serialize zoned dt info using chrono can basically send a timestamp and a timezone name on the wire, e.g. (1721599162, "America/New_York").

            It’s not built-in support. It’s not a single human-readable string containing all the needed info that is being sent on the wire. But it does provide the needed info to get the correct results on the other side. And it’s the obvious solution to do, and it’s doable with trivial wrappers. No Local+FixedOffset usage required. And no wrong results inevitable.

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

              It’s not built-in support.

              Right. That’s exactly what the code snippet says:

                  // The serialized datetime has no time zone information,
                  // so unless there is some out-of-band information saying
                  // what its time zone is, we're forced to use a fixed offset:
              

              So I feel like the point you’re making here is already covered by the example comparison I wrote. It’s not built-in, so you have to invent your own interchange format. And since your serialized format doesn’t include offset information at the time the instant was created, it’s impossible to do offset conflict resolution. For example, let’s say you record one year from today in Ukraine:

              use jiff::{ToSpan, Unit, Zoned};
              
              fn main() -> anyhow::Result<()> {
                  let now = Zoned::now().round(Unit::Minute)?.intz("Europe/Kyiv")?;
                  let next_year = now.checked_add(1.year())?;
                  println!("{next_year}");
                  Ok(())
              }
              

              And the output:

              $ cargo -q r
              2025-07-22T17:23:00+03:00[Europe/Kyiv]
              

              And maybe you store this datetime somewhere.

              At this point, it’s looking like Ukraine is going to abolish DST for next year. So what happens to that datetime above? It no longer has the right offset. So now you need to choose whether to reject it altogether (the default), respect the offset (even if the civil time changes) or respect the civil time (even if the instant changes).

              Here’s an example of when this happened with Brazil abolishing DST: https://docs.rs/jiff/latest/jiff/fmt/temporal/struct.DateTimeParser.html#example-3

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

                Why is the full presentation non-ephemerally stored instead of (timestamp, timezoe)?

                Is the use-case strictly limited to checking the validity of a future date that was generated with assumptions based on current tzdata info? That’s valid, but quite niche I would argue.

                And one can adjust the wrapper to have (timestamp, timezone, assumed_offset_at_ts). But yes, it can be argued that it’s not idiomatic/automatic/antecedently obvious anymore.

                • burntsushi@programming.devOP
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  5 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.

                • Yoddel_Hickory@lemmy.ca
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  5 months ago

                  And the fact that you need to create a wrapper means that some programmers won’t bother to do it, or won’t know they need to do it. The default case handling timezones correctly will reduce potential errors.

  • runiq@feddit.org
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    5 months ago

    Oh hi, didn’t realize you’re here! I xposted this to rust@lemmy.ml.

    Edit: Also you missed an excellent opportunity to name your time-handling library biff

  • Perma@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    5 months ago

    I really likes this package. And I may use it immediately. Very complete and detailed documentation. It lacks in some conveniences like iso8601, rfc3339 or other presets for formatting. But those can be handled manually. Thanks for this!

    • burntsushi@programming.devOP
      link
      fedilink
      English
      arrow-up
      6
      ·
      5 months ago

      You should absolutely not need to handle ISO 8601 and RFC 3339 manually. They are supported via the Display and FromStr trait implementations on every main type in Jiff (Span, Zoned, Timestamp, civil::DateTime, civil::Date and civil::Time). It’s technically an implementation of a mixture of ISO 8601, RFC 3339 and RFC 9557, but the grammar is specified precisely by Temporal. See: https://docs.rs/jiff/latest/jiff/fmt/temporal/index.html

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        5 months ago

        Speaking of convenient things best not handled manually, do you have any plans to get support for it into crates like sqlx-postgresql, diesel or humantime where conversions need to happen but pretty much the same way for every user of the library?

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

          Yeah this is a tough one. I’m not sure the right thing to do is for me to go around blasting PRs at those projects. They’re probably already carrying support for both chrono and time, and asking them to support a third that is brand new is a bit of a stretch I think. Especially since I’ve promised breaking changes in the not-too-distant future. (Although I would like to do a Jiff 1.0 release about 1 year from now and commit to stability.) At least, I know I’d be hesitant if I were on the other side of it. But maybe folks are more flexible than me, I’m not sure.

          I’ve been noodling on just adding these integrations to jiff itself. I do worry that if I do that, then the integrations will always stay with Jiff, even at 1.0. But maybe there just isn’t another feasible choice.

          But, why do you mention humantime? humantime doesn’t have any integrations with time or chrono. humantime is more like a thin wrapper on top of std::time::Duration and std::time::SystemTime to make parsing and printing a bit nicer.