Jiff: Datetime library for Rust • Hacker News Board

Re: Jiff: Datetime library for Rust

#241

Post by 0x457 » Wed, Jul 24, 2024, 11:26 PM UTC

DemocracyFTW2 wrote: post #198

0x457 wrote: post #181

Earlier quoted context omitted.

> I have so many questions. Not being snarky, but I suggest starting by reading at least a little about traits? None of your questions are really about this library - it's just FromStr and an orphan rule.

To make it clear, I didn't want to be the snark either. Just wondered about the usual things like "locally detectable semantics" and so on. I still think `Library.method( argument )` wins over `argument.method()` for the simple reason that the former has `Library` explicitly mentioned. Also, `door.open()`, really? I think `strongman.open( door )` is just that much clearer, flexible and explicit.

Agree to disagree. I always like expressiveness of Ruby, so `2.days` and `2.days()` look totally normal to me.

> `strongman.open( door )` is just that much clearer, flexible and explicit.

Where the strongman came from? Entirely different semantics.

Re: Jiff: Datetime library for Rust

#242

Post by iknowstuff » Thu, Jul 25, 2024, 3:21 AM UTC

demurgos wrote: post #148

burntsushi wrote: post #138

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

Eh, is this ideal with chasing when it’s all fucked anyway when we start shipping code to Mars?

https://en.m.wikipedia.org/wiki/Barycentric_Coordinate_Time

Re: Jiff: Datetime library for Rust

#243

Post by draegtun » Thu, Jul 25, 2024, 11:04 AM UTC

fridder wrote: post #149

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…

If someone wants an entertaining and approachable dive into the insanity that is datetime, Kip Cole did a great talk at ElixirConf in 2022: https://www.youtube.com/watch?v=4VfPvCI901c

To add to this "A Date with Perl" by David Rolsky (video below is from 2017 but he has same talk going back 10+ years).

https://youtu.be/enr5_FoToiA

Re: Jiff: Datetime library for Rust

#244

Post by GoblinSlayer » Thu, Jul 25, 2024, 12:28 PM UTC

Smaug123 wrote: post #238

GoblinSlayer wrote: post #237

Earlier quoted context omitted.

Everybody thinks their philosophy is the best. Take for example C89 time library. You'll just say it doesn't satisfy your philosophy.

I won't just say it doesn't satisfy my philosophy. I'll say additionally that the .NET standard library's `DateTime` type, which I believe is essentially the same and uses basically the same primitives, is so hard to use correctly that I have multiple times had to rewrite other people's programs, in one case completely from the ground up , to fix their correctness due to bugs I personally encountered in them in real…

I only saw DateTime.Now where StopWatch should be used and serialization inconsistency due to discrepancy in time zone database.

Re: Jiff: Datetime library for Rust

#245

Post by Smaug123 » Fri, Jul 26, 2024, 9:33 PM UTC

GoblinSlayer wrote: post #244

Smaug123 wrote: post #238

Earlier quoted context omitted.

I won't just say it doesn't satisfy my philosophy. I'll say additionally that the .NET standard library's `DateTime` type, which I believe is essentially the same and uses basically the same primitives, is so hard to use correctly that I have multiple times had to rewrite other people's programs, in one case completely from the ground up , to fix their correctness due to bugs I personally encountered in them in real…

I only saw DateTime.Now where StopWatch should be used and serialization inconsistency due to discrepancy in time zone database.

So it's famously difficult to write a correct date-time handling program, but my empirical observation is that it's considerably easier with a library like Noda Time which actually attempts to model some of the domain beyond "ticks since the epoch".

Re: Jiff: Datetime library for Rust

#246

Post by fanf2 » Sat, Jul 27, 2024, 1:08 PM UTC

weinzierl wrote: post #118

fanf2 wrote: post #103

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

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.

Leap minutes are not, realistically, going to happen. The proposed bound on DUTC is something like 100s, and that bound is not fixed. The reason for keeping a bound is to appease those who don’t want to give up on it, but in practice once leap seconds have been abolished the bound will be extended not enforced.

Re: Jiff: Datetime library for Rust

#247

Post by fanf2 » Sat, Jul 27, 2024, 1:11 PM UTC

zokier wrote: post #108

fanf2 wrote: post #103

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

Do you also need to account for rubber seconds in the pre-1972 version of UTC?

Re: Jiff: Datetime library for Rust

#248

Post by berkes » Sun, Jul 28, 2024, 5:10 PM UTC

freeopinion wrote: post #218

nindalf wrote: post #70

Earlier quoted context omitted.

And we're going to say "let's do this a day from now", leaving the software to decide whether that's 24, 23 or 25 hours from now. It could be any of those things, depending on where it was said and the DST changes for that timezone. Or conversely, is a specified instant considered "tomorrow"?

I generally consider "tomorrow" to be an interval and not an instant. It is ambigous how large of an interval it is and how far in the future it begins.

"tomorrow" in the real world is also surprisingly complex.

I once built a calendar and reservation system for a theatre that did movies, theatre, concerts and parties. A party that starts Friday at 22:00 and ends at 1:30 doesn't end "tomorrow" in people's minds, it ends Friday night.

(And a party, concert or movie that technically starts Sunday, 00:15 still has to show up on Saturday night 00:15, because that's how everyone looks for it)

Re: Jiff: Datetime library for Rust

#249

Post by GoblinSlayer » Tue, Jul 30, 2024, 6:20 PM UTC

Smaug123 wrote: post #245

GoblinSlayer wrote: post #244

Earlier quoted context omitted.

I only saw DateTime.Now where StopWatch should be used and serialization inconsistency due to discrepancy in time zone database.

So it's famously difficult to write a correct date-time handling program, but my empirical observation is that it's considerably easier with a library like Noda Time which actually attempts to model some of the domain beyond "ticks since the epoch".

How noda prevents you from using utc instead of StopWatch?