30 ms·

Jiff: Datetime library for Rust

• p0w3n3d 2y ago
  Name is pretentious. Jiff? Seriously? How do you read it? "Gif"????
• mleonhard 2y ago
  Thanks for making this library, BurntSushi. impl Decimal { ... /// Returns the ASCII representation of this decimal as a string slice. pub(crate) fn as_str(&self) -> &str { // SAFETY: This is safe because all bytes written to `self.buf` are // guaranteed to be ASCII (including in its initial state), and thus, // any subsequence is guaranteed to be valid UTF-8. unsafe { core::str::from_utf8_unchecked(self.as_bytes()) } } } https://github.com/BurntSushi/jiff/blob/08dfdde204c739e38147faf70b648e2d417d1c2e/src/fmt/util.rs#L186 https://github.com/BurntSushi/jiff/blob/08dfdde204c739e38147... How much performance does `from_utf8_unchecked` buy us over `from_utf8`? It's saving iterating over a 20-byte array. Because the array fits in a single cache line, the iteration will run at the CPU's internal clock rate. I expect that a benchmark would not be able to detect the CPU time saved. Even a program that was only serializing these Decimal types at GB/s, the difference would be barely measurable. As software engineers, about 80% of our time is spent coding. And about 80% of coding time is spent learning how the thing works. If we prioritize code clarity, we speed up 64% of our future work. Performance optimizations always make code less clear. Using `from_utf8_unchecked` is a performance optimization. It makes the code less clear so it needs a three-line comment. Engineering is all about trade-offs. Performance optimizations can be worth their clarity cost when they bring tangible benefits. Therefore, we need to measure. The comment doesn't say "Using `from_utf8_unchecked` because it takes 1ns while `from_utf8` takes 5ns." To make sure we're making a good tradeoff between clarity and performance, we need to measure the impact of the optimization and document it in the code. Using `unsafe` also has a cost. Safety depends on invariants. Future changes to the code can break these invariants. The compiler is the most reliable method for detecting invariant-breakage. Let's take advantage of it. This means using `unsafe` only when its use brings tangible benefits that outweigh the risks. I started my professional life as a Windows sysadmin. Dealing with worms and viruses was a large and unpleasant part of my job. During university, I learned about formal verification of software. It has great potential for making our software secure. Unfortunately, the tools are very hard to use. To verify a program, one must translate it into the language of the verification tool. This is a lot of effort so few projects do it. Now with Rust, we get verification FOR FREE! It's amazing!!!! So let's use it and move our industry forward. Let's make worms, viruses, ransomware, and data theft, into things from the barbaric early days.
  • burntsushi 2y ago
    My micro-benchmark says it is good for a 15% improvement. We've had discussions before about the use of `unsafe` in Rust and we have a pretty clear disagreement about how to balance the trade-offs surrounding it. I have zero interest in re-litigating that discussion with you. I also personally find your conversational style condescending, which makes it difficult for me to talk to you.
• kkjkj 2y ago
  [dead]
• sushibowl 2y ago
  Overall this looks nice, but I found myself stumbling over the ToSpan syntax: let span = 5.days().hours(8).minutes(1); It feels sort of weird how the first number appears in front, and then all the other ones are function arguments. I suppose if you don't like that you can just write: let span = Span::new().days(5).hours(8).minutes(1); at the expense of a couple characters, which is not too bad.
  • bestouff 2y ago
    Or even better: let span = Span::days(5).hours(8).minutes(1);
    • burntsushi 2y ago
      I believe this could actually not work. You would need a `fn days(n: i64) -> Span` and a `fn days(self, n: i64) -> Span` to exist at the same time, which Rust does not allow.
  • Galanwe 2y ago
    If only Rust had named function parameters, you could write what is IMHO the most readable option: Span::new(days=5, hours=8, minutes=1)
    • DemocracyFTW2 2y ago
      could you do that with `struct` / `record` fields? In JavaScript which doesn't have named function parameters either I often write functions with a single `cfg` parameter that are called like `f({ hours: 2, seconds: 53, })` which I find nice b/c it re-uses existing data structures.
      • Galanwe 2y ago
        Well the beautiful thing about software engineering is that pretty much everything is possible, it essentially boils down to "but should you really"? :-)
      • 2y ago
• sam0x17 2y ago
  Not to mention that BurntSushi is the author of the entire rust regex ecosystem
  • dhosek 2y ago
    I remember getting into a debate with him on Reddit about something or other and then realizing who I was debating with and saying never mind.
    • ramon156 2y ago
      That shouldn't stop you from settling an argument (given it was respectful). The best way to learn is to be wronged by smarter people.
      • komadori 2y ago
        Also, just because someone is famous/important/etc doesn't mean they're always right. In fact, one of the dangerous things about being famous is the people stop being willing to disagree with you and that can lead to becoming detached and warped as a person.
      • qup 2y ago
        I feel very certain that's not the best way to learn.
        • sam0x17 2y ago
          training data is training data
        • deleted 2y ago
          [deleted]
      • sam0x17 2y ago
        Yeah for example I've given him crap for years for not having the will to bring back compile-time regex in Rust even though all the pieces for it are there in his `regex-automata` crate ;)
• arijun 2y ago
  A little off topic but does anyone know the purpose of dual licensing MIT and the UNLICENSE? It seems like the second should already allow anyone to do whatever they want…
  • nsajko 2y ago
    The "Unlicense" is not considered as serious.
  • GolDDranks 2y ago
    What I gather about the author's thoughts about that, he isn't a fan of copyright in general, and uses UNLICENSE as an ideological statement, plus a practical way of saying "do whatever you want with this", but also slaps the option to use MIT as "something almost as good" because non-standard licenses deter corporate types, which kind of defeats the original "do whatever you want" purpose of UNLICENSE :D
    • globular-toast 2y ago
      That's what I gather from Unlicense too (in fact, this is confirmed in a linked bug thread where the author says he "hates copyright"). I think the author is actually looking for the GPL but doesn't realise it yet. Unlicense can't make something free forever, no matter how hard the author wishes it. GPL can. In other words, Unlicense/MIT is idealistic, GPL is pragmatic. You can't turn off copyright, but you can make it work for the people instead of against them.
      • rahkiin 2y ago
        Not at all. If this library was GPL, any software using it also needs to be GPL. This means all code needs to be open source, which severely limits freedom of makers of end-user software. And almost the whole Rust ecosystem is MIT.
        • richrichardsson 2y ago
          > severely limits freedom of makers of end-user software Ironic for a "free" software license. It would be great if there was a license somewhere inbetween GPL and MIT: you'd be required to upstream (or make available) any changes you made to the parts of other people's code you're making use of, but not required to open your entire codebase.
• tomas789 2y ago
  The state of calendar libraries in Rust is less than ideal. When working with Pandas, there is .tz_convert() and .tz_localize() and that is basically it for timezone conversions. My benchmark for this is: given a date, get first hour of CET/CEST day in UTC. In Pandas a very simple operation. In Chrono, you have to have a NaiveDate, convert to DateTime<FixedOffset> and then to DateTime<Utc>. And there is no pattern in those conversions I managed to find. Sometimes it is a member function, other times a static method on the timezone object. I hope somebody will rectify this at some point. Jiff seems like a step in a right direction but the syntax is sometimes weird. I guess I’d wellcome something more predictable
  • burntsushi 2y ago
    That should be `date(y, m, d).intz("Europe/Rome")?`. If you want to get UTC from there, then add `with_time_zone(TimeZone::UTC)`. > Jiff seems like a step in a right direction but the syntax is sometimes weird. I guess I’d wellcome something more predictable Can you say more? How can Jiff be better?
• nsajko 2y ago
  The title doesn't conform to the HN guidelines, dang.
  • croemer 2y ago
    Came here to say this :) The original tag line is "Jiff is a datetime library for Rust that encourages you to jump into the pit of success."
  • carbonatom 2y ago
    > The title doesn't conform to the HN guidelines, dang. +1 I don't understand why people are downvoting your comment. This title is absolutely a violation of HN guidelines. And a very blatant one no less! Do people not read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html anymore?
    • jodrellblank 2y ago
      Those guidelines say "Please don't post on HN to ask or tell us something. Send it to hn@ycombinator.com.". That's what the parent commenter should have done. And "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."; your comment is commenting about voting, and this guideline sets a precedent that boring reading is not desirable. and "Please don't comment on whether someone read an article. "Did you even read the article?"" which you are doing about the guidelines. and "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting." which reinforces the idea that uninteresting comments are not deisable. "The title is bad" is not a very interesting comment. Pet annoyance recently is seeing people comment "why am I being downvoted? What I said was true" when what they said was arguably true - but also low effort, flamebait, tangent, off-topic, or similar; "it is correct" alone isn't enough. Since this has been annoying me I want to write more, here are examples: Searching Algolia for 'downvoted': https://news.ycombinator.com/item?id=41039279 https://news.ycombinator.com/item?id=41039279 which says "Microsoft is like Disney, they steal from others and trounce others for stealing from them. Absurd people." followed by "Sad to see this extremely historically accurate and relevant comment downvoted.". It's arguably true - but also arguably false - but definitely a single line of low effort flamebait. Actually justifying the claim would be better. And https://news.ycombinator.com/item?id=41027729 https://news.ycombinator.com/item?id=41027729 - about Kamala Harris "I hate to say it yet I don't think she's polling well because even in 2024 I don't think America is ready to allow a woman of colour be POTUS." reply "You’re downvoted, but you’re correct.". Maybe it is correct, but they could at least argue the case for their claim? Something more substantial than a one line which is basically "America racist"? ("Eschew flamebait. Avoid generic tangents. Omit internet tropes." - guidelines). and https://news.ycombinator.com/item?id=41008957 https://news.ycombinator.com/item?id=41008957 CrowdStrike thread -> substantive comment on centralised control and security -> risks of splaying personal valuables out in front of everyone at security -> security tried to screw me because they had to do their job -> I got downvoted "by some swede who doesn't think this stuff can happen"; assuming the downvote is because people don't believe it happened, rather than because it's marginally - if at all - relevant, substantive, thoughtful, interesting.
• alfiedotwtf 2y ago
  I've been dealing with time and timezones for a long time, but this is the first time I have ever seen the "[Olson/Name]" suffix. Is that actually standard?
  • Nekit1234007 2y ago
    I've seen it being used in ECMAScript's Temporal https://tc39.es/proposal-temporal/docs/strings.html https://tc39.es/proposal-temporal/docs/strings.html
    • alfiedotwtf 2y ago
      Ah, thank you. Now that I'm back at my desk I had to check ISO8601, that suffix is not included. However it does look like an extension - RFC 9557 - which looks like is still in proposed state. I would personally caution using these suffixes until wider adoption, because AFAIK the Olson database names themselves are not standardised on non-POSIX systems (i.e you might have a hard time on Windows).
      • lmz 2y ago
        The database names are standardized: https://www.iana.org/time-zones https://www.iana.org/time-zones The database itself may not be available but there are various implementations including Windows https://data.iana.org/time-zones/tz-link.html#software https://data.iana.org/time-zones/tz-link.html#software
        • alfiedotwtf 2y ago
          Aha! Yeah the last time I needed to play with timezones I had map between Olson and Windows's proprietary names. Looks like they came out their NIH Syndrome: https://learn.microsoft.com/en-gb/archive/blogs/bclteam/exploring-windows-time-zones-with-system-timezoneinfo-josh-free https://learn.microsoft.com/en-gb/archive/blogs/bclteam/expl...
      • bakkoting 2y ago
        "Proposed" is the final state of many stable RFCs; see a list at [1], and compare it to the (much shorter) list of finished standards above it. The name is kind of misleading these days. Some discussion at [2]. Just to give an example, the base64 RFC 4648 is also a "proposed standard". [1] https://www.rfc-editor.org/standards#PS https://www.rfc-editor.org/standards#PS [2] https://datatracker.ietf.org/doc/html/rfc7127#section-2 https://datatracker.ietf.org/doc/html/rfc7127#section-2
• 7bit 2y ago
  So, ist it pronounced jiff or gif?
  • sschueller 2y ago
    The author gets to decide IMO. Gif was always pronounced "jif" according to the creator so I hope the creator of this new tool will pronounce Jiff as "gif" to avoid confusion...
  • runiq 2y ago
    Imma pronounce it biff, it's a time handling library after all.
  • Sharlin 2y ago
    https://github.com/BurntSushi/jiff/blob/master/DESIGN.md#why-name-the-library-jiff https://github.com/BurntSushi/jiff/blob/master/DESIGN.md#why... > Jiff is pronounced like "gif" with a soft "g," as in "gem." Heh, I see what they did there…
    • runiq 2y ago
      We're only minutes away from GAYPEG, an image format which you pronounce with a soft g, like in GIF.
  • neallindsay 2y ago
    Yes
• deleted 2y ago
  [deleted]
• mijoharas 2y ago
  This looks like a cool library. Does anyone know why burntsushi is making this new library? I haven't messed around with times in rust much, but do the existing libraries have performance problems? Or are the existing API's awkward to use? Or is he just doing it for fun, or some other reason?
  • richrichie 2y ago
    [flagged]
  • Sharlin 2y ago
    Linked from the readme: https://github.com/BurntSushi/jiff/blob/master/DESIGN.md https://github.com/BurntSushi/jiff/blob/master/DESIGN.md https://github.com/BurntSushi/jiff/blob/master/COMPARE.md https://github.com/BurntSushi/jiff/blob/master/COMPARE.md TLDR: API and IANA timezone support primarily.
  • tikkabhuna 2y ago
    In Java they had the same problem. The Java standard library implementation wasn't great, Jodatime came along to address those issues. Java 8 then introduced a new DateTime API that was heavily influenced by Jodatime with the benefit that as it is in the standard library, it can be more heavily adopted by library-writers. https://www.joda.org/joda-time/ https://www.joda.org/joda-time/ https://www.baeldung.com/java-8-date-time-intro https://www.baeldung.com/java-8-date-time-intro
    • WorldMaker 2y ago
      There's an additional related stepping stone here (as it is name dropped in the library's design document as well) in that TC-39 has been hard at work on a proposal to standardize similar APIs into EcmaScript (JS) called Temporal: https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/ Temporal benefits from the JodaTime/Java 8+ date work, but also includes more recent IETF and IANA standards as other influences.
• noxs 2y ago
  The fact that we need a such complicated datetime library just means so many unncessary artificial complexities were introduced before (yes the daylight saving, leap seconds etc.)
  • berkes 2y ago
    > unncessary artificial complexities The very fact they are there, still used, and so on, contradicts "unnessary [sic]". Sure, it might be outdated now, or technically better alternatives might be there. But, in the end, software that deals with "The Real World" is going to be a complex, illogical mess. Because the real world is a complex, illogical mess. We could make a time that is global, counts resonant frequency of atoms. While technically superior, I will continue saying "The job took me 3h25 minutes" and not "The job took me 113,066,170,771,000,000 cycles", or even "The job took me 113066 Tera-cycles." or such. Messy, illogical and complex is often simply more practical. If only because "everyone does it that way".
    • nindalf 2y ago
      And we're going to say "let's do this a day from now", leaving the software to decide whether that's 24, 23 or 25 hours from now. It could be any of those things, depending on where it was said and the DST changes for that timezone. Or conversely, is a specified instant considered "tomorrow"?
      • freeopinion 2y ago
        I generally consider "tomorrow" to be an interval and not an instant. It is ambigous how large of an interval it is and how far in the future it begins.
        • nindalf 2y ago
          "Tomorrow" is an interval. I meant to say, is a specified instant within the "tomorrow" interval?
        • berkes 2y ago
• raasdnil 2y ago
  Has to be pronounced gif right?
• returnfalse 2y ago
  Looks cool, thank you burntsushi for this. I have similar complaints about existing date-time libraries in rust. I’ll replace chrono/time with Jiff in my projects.
• sva_ 2y ago
  It's pronounced 'Giff' (with a hard 'G')
  • sapiogram 2y ago
    Non-native speaker here, what does "hard G" even mean? G as in "go", or G as in "gin"?
    • Vinnl 2y ago
      "G" as in "gadverdamme". (Native speaker here - but of Dutch, the language known for its proper hard Gs. Unless you're from the South.)
    • Smaug123 2y ago
      "hard G" is the sound denoted "g" in IPA. The other "g" is "dʒ".
      • n_plus_1_acc 2y ago
        That is the convention in english as least. Other languages may differ.
        • Smaug123 2y ago
          Fortunately, since we are explicitly talking about English here, that convention is indeed the relevant one to use!
    • stonemetal12 2y ago
      Hard G is "go". The name of the format if a play on words, in the US there is a brand of Peanut butter called "Jiff". The file format is supposed to be pronounced the same way (soft G). Some people, like the OP, claim that the G is supposed to be pronounced like the G in graphics (hard G). IDK why anyone cares.
• drtgh 2y ago
  IMHO, unwrap() , expect() and company, has infected the Rust language so deeply that one wonders when (and not "if") will a library send a panic and crash the whole program. How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? beside is promoted from all the Rust's tutorials and reference code. So much correctness in the Rust language just for to promote to all the community to crash the program from libraries without handling the error is something I can not understand. I hope this philosophy do not reach the Linux kernel.
  • db48x 2y ago
    What does this have to do with anything?
    • diggan 2y ago
      Trying to figure this out as well... Tests have a bunch of .expect and .unwrap (which is to be expected), but core logic of the library doesn't seem to have any that seems they'll get in the way?
    • hypeatei 2y ago
      It's done in bad faith. Some are vehemently against Rust because of the "culture" around criticizing other languages' memory safety models, namely C/C++.
      • db48x 2y ago
        You may be right.
        • drtgh 2y ago
          It is not the case, not bad faith intended. To think it is a protest may be nearer. Build in release a hello world, Build in release the example of this library (replacing the assert_eq by a println!("{}", zoned) or other ), or even a different library if it have a large dependence tree. Open on a text editor both files. The presence of the string messages for "unwrap" increased, right? One can observe the code in this library take care of making reach the user the errors in most the parts of the library, so: how was increased the string messages for "unwrap"? How can one know from were they came from? One ends up having to read all the dependencies^5, from were almost always a unwrap() reach the runtime of the release build.
• zokier 2y ago
  While this does seem to be an improvement in general, I find it extremely disappointing that we now got another, greenfield, library that ignores leap seconds and continues the propagation of UNIXy time. I appreciate that it was at least informed decision, and seems to have been tough call to make. So full respect to burntsushi nevertheless. That makes it mostly uninteresting to me; nice api is nice to have, but I'd personally appreciate correct results more. From the wider ecosystem C++ std::chrono seems like the only one that shows some promise on this front. Last I checked the implementations were not there quite yet though, and the API definitely didn't seem all that pleasant. Maybe in couple of years we'll see how it'll work out. Hifitime 4.0 seems like almost the only option at this point, and it is in early alpha still. I recall using astropy at one point just for time calculations, but it is quite overkill solution. The quest for perfect datetime lib (for any language) continues.
  • fanf2 2y ago
    Leap seconds are being abolished. The current rotation speed of the earth is very close to 24h/day and is changing very slowly, so it is not very likely there will be another leap second before they are abolished.
    • zokier 2y ago
      That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.
      • fanf2 2y ago
        Do you also need to account for rubber seconds in the pre-1972 version of UTC?
      • spenczar5 2y ago
        The nice thing is that you would have a static table of leap seconds, and would not need to poll a URL to check for new leap second data (as Astropy does, for example, on import!).
    • 2y ago
• deleted 2y ago
  [deleted]
• magnio 2y ago
  I have seen many people downplaying the complexity of a datetime library. "Just use UTC/Unix time as an internal representation", "just represent duration as nanoseconds", "just use offset instead of timezones", and on and on For anyone having that thought, try reading through the design document of Jiff (https://github.com/BurntSushi/jiff/blob/master/DESIGN.md https://github.com/BurntSushi/jiff/blob/master/DESIGN.md), which, as all things burntsushi do, is excellent and extensive. Another good read is the comparison with (mainly) chrono, the de facto standard datetime library in Rust: https://docs.rs/jiff/latest/jiff/_documentation/comparison/index.html https://docs.rs/jiff/latest/jiff/_documentation/comparison/i... Stuffs like DST arithmetic (that works across ser/de!), roundable duration, timezone aware calendar arithmetic, retrospective timezone conflict detection (!), etc. all contribute to a making the library correct, capable, and pleasant to use. In my experience, chrono is a very comprehensive and "correct" library, but it is also rigid and not very easy to use.
  • tnzk 2y ago
    Recently I came across "Theory and pragmatics of the tz code and data" (*) and really enjoyed as a primer on how timezone names are picked and what made tz the current form. (*) https://ftp.iana.org/tz/tzdb-2022b/theory.html https://ftp.iana.org/tz/tzdb-2022b/theory.html
  • TacticalCoder 2y ago
    I love burntsushi's ripgrep and certainly use it all the time, calling it directly from my beloved Emacs (and I do invoke it all the time). If was using ripgrep already years before Debian shipped rg natively. I was also using JodaTime back when some people still though Eclipse was better than IntelliJ IDEA. But there's nothing in that document that contradicts: "just represent duration as nanoseconds". Users needs to see timezones and correct hour depending on DST, sure. Programs typically do not. Unless you're working on stuff specifically dealing with different timezones, it's usually a very safe bet to: "represent duration as milliseconds/nanoseconds". That humans have invented timezones and DST won't change the physics of a CPU's internal clock ticking x billion times per second. Just look at, say, the kernel of an OS that didn't crash on half the planet a few days ago: there are plenty of timeouts in code expressed as milliseconds. Reading your comment could be misinterpreted as: "We'll allow a 30 seconds cooldown, so let's take the current timezone, add 30 seconds to that, save that time as a string with the time 30 seconds from now, complete with its timezone, DST, 12/24 hours representation and while we're at it maybe add exta code logic to check if there's going to be a leap second or not to make sure we don't wait 29 or 31 seconds, then let the cooldown happen at the 'correct' time". Or you could, you know, just use a freakin' 30 seconds timeout/cooldown expressed in milliseconds (without caring about whether a leap second happened or not btw because we don't care if it actually happens after 29 seconds as seen by the user).
• the__alchemist 2y ago
  Comparison with Chrono link: https://github.com/BurntSushi/jiff/blob/master/COMPARE.md#chrono-v0438 https://github.com/BurntSushi/jiff/blob/master/COMPARE.md#ch... This is interesting, in that Rust with Chrono is the best datetime experience I've had in any language.
• mrbluecoat 2y ago
  bonus: it's pronounced like 'gif' ;)
• demurgos 2y ago
  The main issue I have with existing time libraries, in Rust or other ecosystems is poor support for leap seconds. This is mostly caused by using UNIX timestamps instead of TAI internally, and this lib is no different unfortunately. There seems to be some way to support it with tzif files, but it does not have first-class support. Here is the relevant Jiff issue with more details: https://github.com/BurntSushi/jiff/issues/7 https://github.com/BurntSushi/jiff/issues/7 UNIX timestamps don't use the SI second definition (instead it's 1/86000th of the current day, all UNIX seconds don't have the same duration) which breaks all correct duration computations. I understand that the tradeoff was to inherit compat with older time tracking methods and enable faster calendar formatting, I disagree that it was the right trade-off. UNIX timestamps mix representation concerns with data. In my opinion, leap seconds should be treated exactly like the 29th of February or time zones.
  • burntsushi 2y ago
    Why do you want it? What's your use case? And why doesn't a specialized scientific library like `hifitime` work for your use case? Whenever people talk about leap seconds, it always seems to be in some abstract notion. But it's very rare to see folks connect them to real world use cases. I get the scientific use case, and I feel like that's well served by specialized libraries. Do we need anything else? I'm not sure that we do.
    • demurgos 2y ago
      This is about the "pit of success", being correct and predictable by default. A difference of timestamps not returning the corresponding elapsed wall-time is _very_ surprising. I want to be able to compute durations between timestamps stored in the DB, received from API calls or retrieved from the system and get the right duration "out of the box". Computing these durations lets me apply business logic relying on it. A message can be editable for x amount of time, a token is valid for y amount of time, a sanction expires after z amount of time, etc. For example, I want to issue some token valid for 60s. What should I set the expiry time to? `now + 60s`. Except if `now` is 2016-12-31T23:59:30Z, then most libs will return a time 61s in the future. 1 second may not be a big error, but it's still an error and depending on context it may be relevant. This is a systematic error unrelated to time sync / precision concerns, so it's pretty frustrating to see it being so common. It seems though that we won't have any new leap seconds in the near future so eventually it will just become a curiosity from the past and we'll be stuck with a constant offset between UNIX and TAI. > I feel like that's well served by specialized libraries. Agreed that you need a specialized lib for this, but my point is that _you shouldn't have to_ and the current situation is a failure of software engineering. Computing `t2 - t1` in a model assuming global synchronized time should not be hard. I don't mean it as a personal critique, this is not an easy problem solve since UNIX timestamps are baked almost everywhere. It's just disappointing that we still have to deal with this.
• airstrike 2y ago
  > Jiff is pronounced like "gif" with a soft "g," as in "gem." Over my dead body!
  • faitswulff 2y ago
    Well, it had a good run at the top of hackernews for a minute, but I think we can all see its glaring flaws now. I'll stick with chrono † † pronounced "ch" as in "chase" of course, i.e. "trono"
  • JohnTHaller 2y ago
    You pronounce it GIF instead of GIF?!?
  • coldtea 2y ago
    https://x.com/drgonzo123/status/527520297512345600 https://x.com/drgonzo123/status/527520297512345600
  • aceazzameen 2y ago
    Huh, I thought Jiff was pronounced with a hard "J."
• deleted 2y ago
  [deleted]
• jcgrillo 2y ago
  What does it mean for a Span to be negative? This is one thing I really like about Durations, they can't be negative and therefore match physical reality.
  • burntsushi 2y ago
    ISO 8601-2:2019 defines it as: negative duration: duration in the reverse direction to the proceeding time scale Matching "physical reality" is a non-goal. What's important is modeling the problem domain in a way that makes sense to programmers and helps them avoid mistakes. A negative span doesn't give you any extra expressivity that "subtract a span from a datetime" doesn't already give you. Both are a means to go backwards in time. And they line up with human concepts that talk about the past. So for example, if I say, "I went camping 1 year ago." I am expressing a concept that is modeled by a negative span. And there are also just practical benefits to allowing a span to be signed. For example: use jiff::{ToSpan, Unit, Zoned}; fn main() -> anyhow::Result<()> { let now = Zoned::now().intz("Europe/Kyiv")?; let next_year = now.checked_add(1.year())?; let span = now.since((Unit::Month, &next_year))?; println!("{span}"); Ok(()) } Has this output: $ cargo -q r -P12m If negative spans weren't supported, what would the behavior of this routine be? It could return an error. Or maybe an out-of-band sign. I'm not sure. But this seems like the most sensible thing. And of course, Temporal has negative durations too. This design was copied from them.
    • jcgrillo 2y ago
      Thanks for the explanation. I agree signed spans make it easier to express concepts like "1 year ago" vs "1 year from now". And clearly if the concept of a negative duration has made it into the standard then it makes sense to support it. But I do wonder if there's some value still in being precise, if I think I've measured a negative duration--e.g I look at my watch and write down t0, wait a bit, look at my watch again and write down t1 and find t0 > t1--that's something surprising that probably warrants further investigation. The explanation likely isn't "well time just went backwards for a bit there" :P. This happens frequently in computers, though, so maybe making the programmer handle an error each time is excessive.
• andrewfromx 2y ago
  Wow! What timing. I need this. https://github.com/andrewarrow/toggl https://github.com/andrewarrow/toggl I’m doing UTC conversion in my head.
• pkulak 2y ago
  Thank you! Dealing with time, calendars and durations has always been the hardest part of Rust for me. And yes, I’m including the borrow checker and async! It’s so painful to come from something like the JVM where time operations and formed in near natural language. From a quick glance, this looks even better than java.time.
• hardwaresofton 2y ago
  "babe wake up, the new burntsushi just dropped"[0] On a serious note, any rustaceans in here know the reason the crate doesn't use something like `tracing`? A bit too heavyweight maybe -- it is about half the size on crates? `log` is of course fine, and I don't know that tracing down to the calls for tz operations is a normal use case, but always interested to know if there was a specific why here. [0] https://knowyourmeme.com/memes/wake-up-babe https://knowyourmeme.com/memes/wake-up-babe
  • burntsushi 2y ago
    I think `log` is the lower common denominator, right? And `tracing` interops with it just fine? That's why I used it in Jiff I guess. And it's also been the thing I've been using since the birth of crates.io itself. Jiff doesn't have any requirements other than emitting messages at a specific log level. But no, I'm sure `tracing` would have worked fine too.
    • hardwaresofton 2y ago
      Ah thanks for explaining the rationale and thanks for the lib! The thoughtful compare/contrast with chrono was an excellent read
• durandal1 2y ago
  I really think Rust should adopt one of the popular datetime crates into the std lib - it's not reasonable to offload researching maintainer status and quality to each developer needing to use dates correctly.
  • bobbylarrybobby 2y ago
    Rust’s stdlib is intentionally minuscule so that breaking changes can be made to important crates. Once a crate becomes part of Rust, no breaking change can ever be made to it, which is a pretty high risk situation (if chrono had been added, jiff would not be able to). Better would be for Rust to simply fund development of critical crates and let the marketplace work out which crates those are.
    • bigstrat2003 2y ago
      I think that Rust's tiny stdlib is one of the most glaring flaws of the language. I don't think that there's actually any significant upside, because people can always just use a crate if they want. On the other hand, there's significant downside because not everyone has the ability to install crates. The stdlib is the one thing that is guaranteed to be present, and it should have the most commonly used features developers will need.