Has to be pronounced gif right?
Jiff: Datetime library for Rust
51–60 of 249 posts
Re: Jiff: Datetime library for Rust
#52The title doesn't conform to the HN guidelines, dang.
Came here to say this :)
The original tag line is "Jiff is a datetime library for Rust that encourages you to jump into the pit of success."
Re: Jiff: Datetime library for Rust
#53Earlier quoted context omitted.
What I gather about the author's thoughts about that, he isn't a fan of copyright in general, and uses UNLICENSE as an ideological statement, plus a practical way of saying "do whatever you want with this", but also slaps the option to use MIT as "something almost as good" because non-standard licenses deter corporate types, which kind of defeats the original "do whatever you want" purpose of UNLICENSE :D
That's what I gather from Unlicense too (in fact, this is confirmed in a linked bug thread where the author says he "hates copyright"). I think the author is actually looking for the GPL but doesn't realise it yet. Unlicense can't make something free forever, no matter how hard the author wishes it. GPL can. In other words, Unlicense/MIT is idealistic, GPL is pragmatic. You can't turn off copyright, but you can make…
Not at all. If this library was GPL, any software using it also needs to be GPL. This means all code needs to be open source, which severely limits freedom of makers of end-user software.
And almost the whole Rust ecosystem is MIT.
Re: Jiff: Datetime library for Rust
#54Earlier quoted context omitted.
If only Rust had named function parameters, you could write what is IMHO the most readable option: Span::new(days=5, hours=8, minutes=1)
Yes, that could've been lended almost as-is from OCaml, in particular as Rust doesn't have partial application so optional arguments would work out-of-the-box as well.
Are named arguments on the roadmap somewhere? Or is it a won't-fix?
Re: Jiff: Datetime library for Rust
#55The fact that we need a such complicated datetime library just means so many unncessary artificial complexities were introduced before (yes the daylight saving, leap seconds etc.)
> unncessary artificial complexities
The very fact they are there, still used, and so on, contradicts "unnessary [sic]". Sure, it might be outdated now, or technically better alternatives might be there.
But, in the end, software that deals with "The Real World" is going to be a complex, illogical mess. Because the real world is a complex, illogical mess. We could make a time that is global, counts resonant frequency of atoms. While technically superior, I will continue saying "The job took me 3h25 minutes" and not "The job took me 113,066,170,771,000,000 cycles", or even "The job took me 113066 Tera-cycles." or such. Messy, illogical and complex is often simply more practical. If only because "everyone does it that way".
Re: Jiff: Datetime library for Rust
#56Overall 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.
Yeah, or there could simply be a `days()` free function (and equivalents of the other methods too). No need for struct constructors to be associated functions.
I haven't tried it (so I'm sorry if it's wrong or not what you're talking about) but can't you get a freestanding days function by
use jiff::ToSpan::days;Re: Jiff: Datetime library for Rust
#57Earlier quoted context omitted.
The unlicense is considered problematic in various jurisdictions, among them Germany - under German law, you cannot relinquish certain rights that are associated with the author at all. Dedicating something to the public domain is not a valid concept here. This means the whole license could be declared invalid in court. Other jurisdictions may be similarly problematic- thus the fallback to MIT There’s a stackoverflow…
My own summary and collection of information about the problems with the Unlicense: https://chrismorgan.info/blog/unlicense/ (I collected that mostly because I didn’t find all the relevant information in one place, or explanation of the reasonable alternatives.)
That looks like a pretty comprehensive overview. I'll bookmark this for further reference :)
Re: Jiff: Datetime library for Rust
#58Earlier quoted context omitted.
That's what I gather from Unlicense too (in fact, this is confirmed in a linked bug thread where the author says he "hates copyright"). I think the author is actually looking for the GPL but doesn't realise it yet. Unlicense can't make something free forever, no matter how hard the author wishes it. GPL can. In other words, Unlicense/MIT is idealistic, GPL is pragmatic. You can't turn off copyright, but you can make…
Not at all. If this library was GPL, any software using it also needs to be GPL. This means all code needs to be open source, which severely limits freedom of makers of end-user software. And almost the whole Rust ecosystem is MIT.
> severely limits freedom of makers of end-user software
Ironic for a "free" software license.
It would be great if there was a license somewhere inbetween GPL and MIT: you'd be required to upstream (or make available) any changes you made to the parts of other people's code you're making use of, but not required to open your entire codebase.
Re: Jiff: Datetime library for Rust
#59Looks cool, thank you burntsushi for this. I have similar complaints about existing date-time libraries in rust. I’ll replace chrono/time with Jiff in my projects.
Re: Jiff: Datetime library for Rust
#60It's pronounced 'Giff' (with a hard 'G')