Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jiff: Datetime library for Rust

github.com

Post reply on HN
Print view View original

221–230 of 249 posts

Re: Jiff: Datetime library for Rust

#221

Post by Smaug123 »

GoblinSlayer wrote: post #217
Smaug123 wrote: post #98

Earlier quoted context omitted.

They can certainly be simple and incomplete, or simple and incorrect; do you have an example of a simple, complete, and correct time library?

You think your philosophy is stronger than any other philosophy? I mean it's philosophic design approach itself which is doubtful. Correctness is satisfaction of expectations. For any library there are expectations that it doesn't satisfy.

Is that relevant? If my philosophy is weak, you can prove it to be weak by providing me with an example of a library which conforms to a better philosophy; then I can see why it's better.

Re: Jiff: Datetime library for Rust

#222

Post by Tobu »

burntsushi wrote: post #205
stouset wrote: post #203

Earlier quoted context omitted.

What's the issue with having a span represent "one year and two months"? Both involve a variable number of days (365-366 and 28-31), but I would hope you could store the components separately so it can be unambiguously applied once given a specific moment in time. I'm thinking something along the lines of how ActiveSupport::Duration works: >> 4.years + 5.months + 3.weeks + 2.days + 1.hour + 4.minutes + 10.seconds =>…

The components are stored separately. I think what you are advocating for is component wise addition, which I mentioned in my previous comment. It can totally "work," but as I said, it will produce different results than `span1.checked_add(span2)`. For example: use jiff::{ToSpan, Unit, Zoned}; fn main() -> anyhow::Result { let span1 = 1.year().months(3); let span2 = 11.months(); let now = Zoned::now().round(Unit::Min…

The Into argument feels a little too magical. Since you are not constrained by a trait, I would prefer something like

    Span::add_with_reference(&self, other: &Span, reference: impl Into)

Re: Jiff: Datetime library for Rust

#223

Post by PoignardAzur »

steveklabnik wrote: post #213
_flux wrote: post #68

Earlier quoted context omitted.

Is it really, though? I didn't read all the comments, but the ones I read, very few were opposing the concept as such: https://internals.rust-lang.org/t/pre-rfc-named-arguments/16... However, many were opposing overloading the same pre-rfc was suggesting.

https://github.com/rust-lang/rfcs/issues/323 is the oldest currently open tracking issue, as you can see it has 397 comments. And that thread you linked has 171. Basically, tons of people that feel basically every possible way. I also feel at this point it's basically a wontfix, but that's more because it's both controversial and huge, and arguably not as high of a priority as other things even if it weren't those tw…

Variadic*

Re: Jiff: Datetime library for Rust

#224

Post by michaelcampbell »

coldtea wrote: post #162
sushibowl wrote: post #3

Overall this looks nice, but I found myself stumbling over the ToSpan syntax: let span = 5.days().hours(8).minutes(1); It feels sort of weird how the first number appears in front, and then all the other ones are function arguments. I suppose if you don't like that you can just write: let span = Span::new().days(5).hours(8).minutes(1); at the expense of a couple characters, which is not too bad.

I like your version's consistency. The original looks like something Ruby would do.

Only in your memory, I think.

> let span = 5.days().hours(8).minutes(1); # "original"

Actual ruby (with Rails extensions; stock ruby doesn't do this)

    irb(main):001> now = Time.now
    => 2024-07-23 08:31:53.656455305 -0400
    irb(main):002> now + 4.days + 8.minutes + 2.hours
    => 2024-07-27 10:39:53.656455305 -0400
So the version of his that you like for "consistency" is far more closely aligned to what ruby/rails _actually_ does.

Re: Jiff: Datetime library for Rust

#225

Post by nindalf »

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" is an interval. I meant to say, is a specified instant within the "tomorrow" interval?

Re: Jiff: Datetime library for Rust

#226

Post by estebank »

steveklabnik wrote: post #214
kibwen wrote: post #182

Earlier quoted context omitted.

Has anyone ever proposed it? It's such a straightforward feature with such obvious semantics ("default field values are const contexts") and impossible-to-bikeshed syntax (`a: i32 = 42`) that I've been meaning to write up an RFC myself for around, oh, ten years now...

nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806 It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...

Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me.

1: https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-suga...

Re: Jiff: Datetime library for Rust

#227

Post by steveklabnik »

estebank wrote: post #226
steveklabnik wrote: post #214

Earlier quoted context omitted.

nrc was poking at the problem in 2016 https://internals.rust-lang.org/t/struct-field-defaults/3412 which led to this RFC https://github.com/rust-lang/rfcs/pull/1806 It got postponed because it wasn't going to make it into Rust 2018: https://github.com/rust-lang/rfcs/pull/1806#issuecomment-327...

Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me. 1: https://internals.rust-lang.…

Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.

Re: Jiff: Datetime library for Rust

#228

Post by steveklabnik »

PoignardAzur wrote: post #223
steveklabnik wrote: post #213

Earlier quoted context omitted.

https://github.com/rust-lang/rfcs/issues/323 is the oldest currently open tracking issue, as you can see it has 397 comments. And that thread you linked has 171. Basically, tons of people that feel basically every possible way. I also feel at this point it's basically a wontfix, but that's more because it's both controversial and huge, and arguably not as high of a priority as other things even if it weren't those tw…

Variadic*

Thanks!

Re: Jiff: Datetime library for Rust

#229

Post by estebank »

steveklabnik wrote: post #227
estebank wrote: post #226

Earlier quoted context omitted.

Last time I had this conversation[1] the main sticking point were around semantics of private fields, but I am convinced that the maximally restrictive version can be done (only pub fields can be optional) and maybe relaxed later after we get some real world experience. The other thing was about whether the default values needed to be const, but that makes sense as a restriction to me. 1: https://internals.rust-lang.…

Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.

The issue I have with Default is that the verbosity jump from derive(Default) to impl Default for Type is high, evej if you just want to specify a single field. The other reason I want this is because it makes defining builders almost trivial for any case where custom logic isn't needed for the fields. I would expect the impl-based builder pattern to become more niche if we had this feature. Your reason is yet another that would be nice to address as well. I like how this one change addresses multiple things at once.

Re: Jiff: Datetime library for Rust

#230

Post by steveklabnik »

estebank wrote: post #229
steveklabnik wrote: post #227

Earlier quoted context omitted.

Yeah makes sense! I haven’t felt the need for this feature personally, but it feels like it fits with the language pretty well to me. The big issue with default values (as far as I’m concerned) is for them to always have a default value, and this doesn’t change the opt-in nature of the concept.

The issue I have with Default is that the verbosity jump from derive(Default) to impl Default for Type is high, evej if you just want to specify a single field. The other reason I want this is because it makes defining builders almost trivial for any case where custom logic isn't needed for the fields. I would expect the impl-based builder pattern to become more niche if we had this feature. Your reason is yet anothe…

Yeah, full agreement here. I almost said something along the lines of "it's almost like extending #[derive(Default)] with serde-like attributes to control which fields get what defaults, but with nicer syntax," but got a little lazy with it since we're in agreement anyway. It is annoying that deriving Default is all or nothing.

I didn't even think about the builder thing, but you're right there too.

Post reply on HN