Live data from Hacker News

Jiff: Datetime library for Rust

github.com

111–120 of 249 posts

Re: Jiff: Datetime library for Rust

#112
post #32

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

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 ;)

Re: Jiff: Datetime library for Rust

#113
post #30
post #23

Earlier quoted context omitted.

It's implied. Here is the full syntax. > let time: Timestamp = "2024-07-11T01:14:00Z".parse:: ()?;

That :: thing at the end is called a turbofish. It is rarely necessary to give it explicitly (but sometimes you do when the compiler cannot infer the return type on its own—thusfar in my own rust coding I’ve needed it exactly once).

It’s useful to know the full syntax, I’ve definitely encountered needing it more than one time.

Re: Jiff: Datetime library for Rust

#114
post #48

Earlier quoted context omitted.

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.

I feel very certain that's not the best way to learn.

training data is training data

Re: Jiff: Datetime library for Rust

#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 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/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.

Re: Jiff: Datetime library for Rust

#117
post #47
post #21

So, ist it pronounced jiff or gif?

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…

We're only minutes away from GAYPEG, an image format which you pronounce with a soft g, like in GIF.

Re: Jiff: Datetime library for Rust

#118
post #103
post #95

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…

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.

While leap seconds are planned to be abolished, there is no plan to give up the coupling of UTC and the Earth's angle.

Leap seconds are just to be replaced by a yet to be defined adjustment, likely leap minutes.

If you don't like leap seconds and don't care about a small (but increasing) deviation from Earth's angle you can do so today: Just use TAI.

Re: Jiff: Datetime library for Rust

#120
post #95

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…

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?

Post reply on HN