I love to code.

  • 2 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: September 8th, 2023

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





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


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



  • 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


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







  • Cross-posting from reddit:

    The PR has more details, but here are a few ad hoc benchmarks using ripgrep on my M2 mac mini while searching a 5.5GB file.

    This one is just a case insensitive search. A case insensitive regex expands to something like (ignoring Unicode) [Ss][Hh][Ee][Rr]..., which means that it has multiple literal prefixes. In fact, you can enumerate them! As long as the set is small enough, this is something that the new SIMD acceleration on aarch64 can handle (and has done for a long time on x86-64):

    $ time rg-before-teddy-aarch64 -i -c 'Sherlock Holmes' OpenSubtitles2018.half.en
    3055
    
    real    8.208
    user    7.731
    sys     0.467
    maxmem  5600 MB
    faults  191
    
    $ time rg-after-teddy-aarch64 -i -c 'Sherlock Holmes' OpenSubtitles2018.half.en
    3055
    
    real    1.137
    user    0.695
    sys     0.430
    maxmem  5904 MB
    faults  203
    

    And of course, using multiple literals explicitly also uses this optimization:

    $ time rg-before-teddy-aarch64 -c 'Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty' OpenSubtitles2018.half.en
    3804
    
    real    9.055
    user    8.580
    sys     0.474
    maxmem  4912 MB
    faults  11
    
    $ time rg-after-teddy-aarch64 -c 'Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty' OpenSubtitles2018.half.en
    3804
    
    real    1.121
    user    0.697
    sys     0.422
    maxmem  4832 MB
    faults  11
    

    And it doesn’t just work for prefixes, it also works for inner literals too:

    $ time rg-before-teddy-aarch64 -c '\w+\s+(Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty)\s+\w+' OpenSubtitles2018.half.en
    773
    
    real    9.065
    user    8.586
    sys     0.477
    maxmem  6384 MB
    faults  11
    
    $ time rg-after-teddy-aarch64 -c '\w+\s+(Sherlock Holmes|John Watson|Irene Adler|Inspector Lestrade|Professor Moriarty)\s+\w+' OpenSubtitles2018.half.en
    
    773
    
    real    1.124
    user    0.702
    sys     0.421
    maxmem  6784 MB
    faults  11
    

    If you’re curious about how the SIMD stuff works, you can read my description of Teddy here. I ported this algorithm out of the Hyperscan project several years ago, and it has been one of the killer ingredients for making ripgrep fast in a lot of common cases. But it only worked on x86-64. With the rise and popularity of aarch64 and Apple silicon, I was motivated to port it over. I just recently finished analogous work for the memchr crate as well.