Jiff: Datetime library for Rust • Hacker News Board

Re: Jiff: Datetime library for Rust

#131

Post by tracker1 » Mon, Jul 22, 2024, 2:30 PM UTC

throwawaymaths wrote: post #128

TacticalCoder wrote: post #122

Earlier quoted context omitted.

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…

> That humans have invented timezones and DST won't change the physics of a CPU's internal clock ticking x billion times per second. Increasingly we are programming in distributed systems. One milli or nano on one node is not a milli or nano on another node, and that is physics that is more inviolable.

In which case, does being off a few milli actually matter that much in any significant number of those distributed instances? No precision is exact, so near enough, should generally be near enough for most things.

It may depend in some cases, but as soon as you add network latency there will be variance regardless of the tool you use to correct for variance.

Re: Jiff: Datetime library for Rust

#132

Post by estebank » Mon, Jul 22, 2024, 2:35 PM UTC

devanl wrote: post #29

DemocracyFTW2 wrote: post #9

Earlier quoted context omitted.

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.

In Rust, you can't implicitly omit fields when instantiating a struct, so it would have to be a bit more verbose, explicitly using Rust's analog to the spread syntax. It would have to look something like: f({ hours: 2, seconds: 53, ..Default::default() }) The defaults could come from some value / function with a name shorter than Default::default(), but it would be less clear.

Adding support for struct default field values would allow for

- leaving some mandatory fields

- reduce the need for the builder pattern

- enable the above to be written as f(S { hours: 2, seconds: 53, .. })

If that feature ever lands, coupled with structural/anonymous structs or struct literal inference, you're getting everything you'd want from named arguments without any of the foot guns.

Re: Jiff: Datetime library for Rust

#133

Post by bigstrat2003 » Mon, Jul 22, 2024, 2:37 PM UTC

drtgh wrote: post #78

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…

> I hope this philosophy do not reach the Linux kernel.

Well, I hope it does. Albeit it almost certainly will not, because Linus is opposed to it. But ever since I read Joe Duffy's blog posts on the Midori research project at MS, I have been convinced that using panics leads to increased reliability, not decreased. From his blog[1]:

"Given that bugs are inherently not recoverable, we made no attempt to try. All bugs detected at runtime caused something called abandonment, which was Midori’s term for something otherwise known as “fail-fast”."

And:

"Abandonment, and the degree to which we used it, was in my opinion our biggest and most successful bet with the Error Model. We found bugs early and often, where they are easiest to diagnose and fix."

I think that the Midori team's work shows that a practice of "there's a bug, stop everything" leads to more reliable software. Sure, there's an initial period of pain where you're fixing a ton of bugs as they cause the software to panic. But you reap the rewards of that effort. I don't think Linux will ever move towards a model like this, but I think it would be beneficial in the end if they did.

1: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...

Re: Jiff: Datetime library for Rust

#134

Post by demurgos » Mon, Jul 22, 2024, 2:38 PM UTC

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

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.

Re: Jiff: Datetime library for Rust

#135

Post by burntsushi » Mon, Jul 22, 2024, 2:39 PM UTC

TacticalCoder wrote: post #122

magnio wrote: post #115

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 ), 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…

I'm not sure what the issue is here exactly, but there are surely use cases where a `std::time::SystemTime` (which you can think of as a Unix timestamp) is plenty sufficient. ripgrep, for example, uses `SystemTime`. But it has never used a datetime library. Just because Jiff exists doesn't all of a sudden mean you can't use `SystemTime`.

But there's a whole world above and beyond timestamps.

Re: Jiff: Datetime library for Rust

#136

Post by stonemetal12 » Mon, Jul 22, 2024, 2:40 PM UTC

sapiogram wrote: post #84

sva_ wrote: post #60

It's pronounced 'Giff' (with a hard 'G')

Non-native speaker here, what does "hard G" even mean? G as in "go", or G as in "gin"?

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.

Re: Jiff: Datetime library for Rust

#137

Post by airstrike » Mon, Jul 22, 2024, 2:41 PM UTC

> Jiff is pronounced like "gif" with a soft "g," as in "gem."

Over my dead body!

Re: Jiff: Datetime library for Rust

#138

Post by burntsushi » Mon, Jul 22, 2024, 2:42 PM UTC

demurgos wrote: post #134

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/is…

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.

Re: Jiff: Datetime library for Rust

#139

Post by burntsushi » Mon, Jul 22, 2024, 2:46 PM UTC

spenczar5 wrote: post #125

burntsushi wrote: post #120

Earlier 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?

I work in astronomy, on detection of asteroids. Catalogs of historical asteroid detections may be reported in UTC from some observatories for historical reasons. Finding a trajectory that matches several candidate detections is called “linking” and it is very sensitive to time. Being off by even one second will result in a predicted position which is far off course, and so a candidate asteroid detection will not be l…

Right, but I address this in the issue linked elsewhere in this thread: https://github.com/BurntSushi/jiff/issues/7

Like yes, scientific applications are a very valid use case for this. But scientific applications usually want other things not afforded by general purpose datetime libraries, like large time ranges and high precision. What I ask in that issue, and what I don't understand, is why folks who want leap second support aren't happy with using specialized libraries for that task, and instead request that leap second support be added to general purpose datetime libraries.

Re: Jiff: Datetime library for Rust

#140

Post by WorldMaker » Mon, Jul 22, 2024, 2:49 PM UTC

tikkabhuna wrote: post #106

mijoharas wrote: post #40

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?

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.baeldung.com/java-8-date-time-intro

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/

Temporal benefits from the JodaTime/Java 8+ date work, but also includes more recent IETF and IANA standards as other influences.