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.
Jiff: Datetime library for Rust
151–160 of 249 posts
Re: Jiff: Datetime library for Rust
#152While 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…
Can you say why you wouldn't want to use a TAI time zone? Like, generate the TZif data for TAI and then just do `jiff::tz::TimeZone("TAI", tzif_data)`. Then you'll get leap second accurate durations. Can you also say why you need the precision? Like, what's the use case? What happens if your program computes durations that are off because of leap seconds?
Going through TAI is probably the best way for me, I'll have to play around with Jiff to see how practical that is. I'm glad if there is good support for TAI though!
One random use-case (reminded by other thread on the front-page) is that I occasionally have needed to analyze some logs, and get some stats from the data. For example having logs like "2024-07-24T14:46:53.123456Z Foo id=42 started" and "2024-07-24T14:46:54.654321Z Foo id=42 finished", and wanting to get some histogram on how long "Foo" took.
Sure, ideally you'd have some explicit metrics/tracing system or some other measurements for getting that data, but unfortunately in practice that is not always the case and I have to make do with what I have.
Or even more simple, I just want to sort bunch of events to establish a timeline. UNIX style time handling makes that difficult.
NTP adjustments can also cause problems in these sort of cases, but at least the systems I work with are usually kept in relatively tight sync so the "window of uncertainty" is much less than 1s.
Re: Jiff: Datetime library for Rust
#153Wow! What timing. I need this. https://github.com/andrewarrow/toggl I’m doing UTC conversion in my head.
Re: Jiff: Datetime library for Rust
#154What 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.
ISO 8601-2:2019 defines it as:
negative duration:
duration in the reverse direction to the proceeding time scale
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(())
}
$ cargo -q r
-P12m
And of course, Temporal has negative durations too. This design was copied from them.
Re: Jiff: Datetime library for Rust
#155Thank 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.
Re: Jiff: Datetime library for Rust
#156Earlier quoted context omitted.
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…
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.…
What I'm not clear on though is what the failure mode is in your scenario. What happens when it's wrong? Does something bad happen? If something is one second longer or shorter than what it ought to be on very rare occasions, then what does wrong? I would, for example, imagine that the business use case of "editable for x amount of time" would be perfectly fine with that being plus-or-minus 1 second. It's not just about correctness, it's about the error and what it means.
A few months ago, Jiff did have leap second support. It worked. I know how to do it, but none of the arguments in its favor seem to justify its complexity. Especially when specialized libraries exist for it. You can't look at this in a vacuum. By make a general purpose datetime library more complex, you risk the introduction of new and different types of errors by users of the library that could be much worse than the errors introduced by missing leap second support.
Re: Jiff: Datetime library for Rust
#157Earlier quoted context omitted.
Can you say why you wouldn't want to use a TAI time zone? Like, generate the TZif data for TAI and then just do `jiff::tz::TimeZone("TAI", tzif_data)`. Then you'll get leap second accurate durations. Can you also say why you need the precision? Like, what's the use case? What happens if your program computes durations that are off because of leap seconds?
Going through TAI is probably the best way for me, I'll have to play around with Jiff to see how practical that is. I'm glad if there is good support for TAI though! One random use-case (reminded by other thread on the front-page) is that I occasionally have needed to analyze some logs, and get some stats from the data. For example having logs like "2024-07-24T14:46:53.123456Z Foo id=42 started" and "2024-07-24T14:46…
I think Jiff should handle that log use case pretty fine? That seems pretty standard. Just parse into a `jiff::Timestamp` and then you can sort or whatever.
Re: Jiff: Datetime library for Rust
#158I 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 ), which, as all things burntsushi do, is excellent and…
>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
Anyone thinking datetimes are easy, should not be allowed near any schedulling or date processing code!
Re: Jiff: Datetime library for Rust
#159> Jiff is pronounced like "gif" with a soft "g," as in "gem." Over my dead body!
Re: Jiff: Datetime library for Rust
#160I 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 ), which, as all things burntsushi do, is excellent and…
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…
Unless you're just using time information to implement a stopwatch on your program, anything you do with time will eventually have to deal with timezones, and DSTs, and leap seconds, and tons of other intricasies.
Even something as simple as schedulling a periodic batch process.