bonus: it's pronounced like 'gif' ;)
Jiff: Datetime library for Rust
121–130 of 249 posts
Re: Jiff: Datetime library for Rust
#122I 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 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).
Re: Jiff: Datetime library for Rust
#123Earlier quoted context omitted.
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.
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.
Well, the flip side of it was that in benchmarking our equivalent codebases for Unicode segmentation, my code was significantly faster, to both of our surprises as it turned out.
Re: Jiff: Datetime library for Rust
#124I 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…
> (that works across ser/de!)
uhg, I can't believe it took me this long to realize why Serde crate is named that!
Re: Jiff: Datetime library for Rust
#125While 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?
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 linked.
Linking is not quite sensitive enough to demand a relativistic time scale, but definitely sensitive enough to require correct leap seconds.
Re: Jiff: Datetime library for Rust
#126While 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…
TBH I consider the C++ `std::chrono` as the worse possible design.
`tai_clock::now` does not actually take into account leap seconds. Unless it does, who knows ("Implementations may use a more accurate value of TAI time.").
Likewise, `tai_clock::from_utc/to_utc` does not correct for leap second. It just translates the UTC epoch to the TAI 1958 epoch.
I found Hifitime to be very opinionated and give a false sense of security due to its automatic computation of leap seconds based on historical tables. Yes, leap seconds are announced some ~6 month in advance, but what if you don't update regularly the library? Or if you can't because it is deployed on an embedded system?
In the end I wrote my own minimalistic TAI timestamp library [1] and made the conscious decision to let the user take the responsibility to deal with leap seconds in UTC conversion.
Re: Jiff: Datetime library for Rust
#127Earlier quoted context omitted.
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.
That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.
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!).
Re: Jiff: Datetime library for Rust
#128I 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…
> 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.
Re: Jiff: Datetime library for Rust
#129I 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…
Of course you don't need a calendar library to measure 30 seconds. That's not the use case.
Try adding one year to a timestamp because you're tracking someone's birthday. Or add one week because of running a backup schedule.
Re: Jiff: Datetime library for Rust
#130I 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…
> (that works across ser/de!) uhg, I can't believe it took me this long to realize why Serde crate is named that!
The abbreviation is also used by EE folks, e.g. SerDes [0]. The capitalization makes it a bit more obvious.