Name is pretentious. Jiff? Seriously? How do you read it? "Gif"????
Jiff: Datetime library for Rust
201–210 of 249 posts
Re: Jiff: Datetime library for Rust
#202I 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.
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.
Re: Jiff: Datetime library for Rust
#203Earlier quoted context omitted.
That isn't an implementation of addition between Spans and other Spans. It looks like there isn't one in the library right now. `impl Add for &'a Zoned` means a borrow of Zoned is on the left hand side, and a Span on the right. So it says that if z is a Zoned (not a Span) and s is a Span, you can do `&z + s` to add a span to a Zoned. There are a bunch of implementations there, DateTime + Span, Date + Span, Time + Spa…
This is correct. You can't do a `span1 + span2`. You'd have to use `span1.checked_add(span2)`. The main problem I had with overloading `+` for span addition is that, in order to add two spans with non-uniform units (like years and months), you need a relative datetime. So `+` would effectively have to panic if you did `1.year() + 2.months()`, which seems like a horrific footgun. It would be plausible to make `+` for…
What's the issue with having a span represent "one year and two months"? Both involve a variable number of days (365-366 and 28-31), but I would hope you could store the components separately so it can be unambiguously applied once given a specific moment in time.
I'm thinking something along the lines of how ActiveSupport::Duration works:
>> 4.years + 5.months + 3.weeks + 2.days + 1.hour + 4.minutes + 10.seconds
=> 4 years, 5 months, 3 weeks, 2 days, 1 hour, 4 minutes, and 10 seconds
Re: Jiff: Datetime library for Rust
#204Earlier quoted context omitted.
Not exactly. It is more like if a library is gonna crash the program (the deep dependencies used in that library triggered a panic on its own), just to let the programmer know it before happens; thus allowing the programmer to try alternatives for to avoid it, and if it's inexorable after those tries, for procedures for a controlled shutdown with proper protocols, actions, and so on. I mean, as the crash is not expos…
How do you let the programmer know? Through the public API... Otherwise you have to catch panics via unwinding.
By the public API then, may be a language generalized Err(panicked) through Result, nothing more as it is about the request cannot be accomplished at all (target/debug would tell), or may be someone thought on simpler tip through compiler or other thing. I humbly do not know what approach would be simpler, efficient or less intrusive, I would embrace anything to avoid sudden crash.
Re: Jiff: Datetime library for Rust
#205Earlier quoted context omitted.
This is correct. You can't do a `span1 + span2`. You'd have to use `span1.checked_add(span2)`. The main problem I had with overloading `+` for span addition is that, in order to add two spans with non-uniform units (like years and months), you need a relative datetime. So `+` would effectively have to panic if you did `1.year() + 2.months()`, which seems like a horrific footgun. It would be plausible to make `+` for…
What's the issue with having a span represent "one year and two months"? Both involve a variable number of days (365-366 and 28-31), but I would hope you could store the components separately so it can be unambiguously applied once given a specific moment in time. I'm thinking something along the lines of how ActiveSupport::Duration works: >> 4.years + 5.months + 3.weeks + 2.days + 1.hour + 4.minutes + 10.seconds =>…
The components are stored separately. I think what you are advocating for is component wise addition, which I mentioned in my previous comment. It can totally "work," but as I said, it will produce different results than `span1.checked_add(span2)`. For example:
use jiff::{ToSpan, Unit, Zoned};
fn main() -> anyhow::Result {
let span1 = 1.year().months(3);
let span2 = 11.months();
let now = Zoned::now().round(Unit::Minute)?;
let added = span1.checked_add((span2, &now))?;
println!("{added}");
Ok(())
}
$ cargo -q r
P2y2m
In contrast, component wise addition would lead to a span of `1 year 14 months`. Which is a valid `Span`. Jiff is fine with it. But it's different than what `checked_add` does. Having both operations seems too subtle.
Also, I don't really think using the `+` operator just to construct spans is that much of a win over what Jiff already has. So that needs to be taken into account as well.
Re: Jiff: Datetime library for Rust
#206Earlier quoted context omitted.
How do you let the programmer know? Through the public API... Otherwise you have to catch panics via unwinding.
By the public API then, may be a language generalized Err(panicked) through Result, nothing more as it is about the request cannot be accomplished at all (target/debug would tell), or may be someone thought on simpler tip through compiler or other thing. I humbly do not know what approach would be simpler, efficient or less intrusive, I would embrace anything to avoid sudden crash.
The juxtaposition between this comment where you seem to have absolutely no idea what you're talking about, and the certainty with which your initial comment was expressed is really quite something.
Re: Jiff: Datetime library for Rust
#207Re: Jiff: Datetime library for Rust
#208The title doesn't conform to the HN guidelines, dang.
> 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 anymore?
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 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 - 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 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.
Re: Jiff: Datetime library for Rust
#209Earlier quoted context omitted.
By the public API then, may be a language generalized Err(panicked) through Result, nothing more as it is about the request cannot be accomplished at all (target/debug would tell), or may be someone thought on simpler tip through compiler or other thing. I humbly do not know what approach would be simpler, efficient or less intrusive, I would embrace anything to avoid sudden crash.
The juxtaposition between this comment where you seem to have absolutely no idea what you're talking about, and the certainty with which your initial comment was expressed is really quite something.
My initial comment was: 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.
Empathy tone changed in such last message which you are ridiculing, it is the point within all my comments, the behavior of a --release.
I should not have had dialogue as the things are not going to change. What I take with me is to think on alternative for panic/unwrap is something only come from ignorance, the best is to crash a program without let the programmer nor the final user to blink; to think in a different behavior in Rust is ridiculous. This is what is really quite something.
Re: Jiff: Datetime library for Rust
#210"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://knowyo…
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.
Ah thanks for explaining the rationale and thanks for the lib! The thoughtful compare/contrast with chrono was an excellent read