[deleted]
Jiff: Datetime library for Rust
101–110 of 249 posts
Re: Jiff: Datetime library for Rust
#102The title doesn't conform to the HN guidelines, dang.
> The title doesn't conform to the HN guidelines, dang.
+1
I don't understand why people are downvoting your comment. This title is absolutely a violation of HN guidelines. And a very blatant one no less!
Do people not read https://news.ycombinator.com/newsguidelines.html anymore?
Re: Jiff: Datetime library for Rust
#103While 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.
Re: Jiff: Datetime library for Rust
#104IMHO, unwrap() , expect() and company, has infected the Rust language so deeply that one wonders when (and not "if") will a library send a panic and crash the whole program. How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? beside is promoted from all the Rust's tutorials and reference code. So much correctness in the Rust language just…
> How could be erased those panic! methods that are used in most of Rust's libraries is something that may be is beyond the possible? It's arguably quite possible, though not as straightforwards as one may hope. For example, there's no_panic, which results in a linker error if the compiler cannot prove a function cannot panic [0], albeit with some caveats. > So much correctness in the Rust language just for to promot…
> Is there that much "promoting" of unchecked unwrap()/expect()/etc. going on? How do you distinguish that from "genuine" cases of violations of the programmer's assumptions?
More like promoted indirectly, I think by being used widely on reference code and tutorials the programmers absorbs as a familiar and quick to write method without planning much. And at same time by not being actively promoted that such methods should not be used within a library runtime or similar at least, because many people do not see it as wrong, what convert it in philosophy I guess.
When the dependency chain of library loading is fired, almost always I checked some unwrap ends within the program's runtime, so distinguishing whether those are genuine cases of violations (IMHO they can't be genuine if a lib can panic the program), or if it was just a unfinished prototyping part or etc, I think is not exactly important as individual until it reach terms of generalized behavior along the language libraries, and even seen in some programs of the community.
> IIRC this is being worked on, especially given Linus's position on panics in the kernel.
These are good news
Re: Jiff: Datetime library for Rust
#105Earlier 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…
Never understood why anyone uses this one; it's just too potentially messy, and a permissive license like 0BSD provides the intended effect without the risk.
Part of the indended effect is making a policical/societal point about the copyright system, something the 0BSD license does not do. I personally believe that legal documents are a bad place to make these points, but obviously people differ.
Re: Jiff: Datetime library for Rust
#106This looks like a cool library. Does anyone know why burntsushi is making this new library? I haven't messed around with times in rust much, but do the existing libraries have performance problems? Or are the existing API's awkward to use? Or is he just doing it for fun, or some other reason?
In Java they had the same problem. The Java standard library implementation wasn't great, Jodatime came along to address those issues. Java 8 then introduced a new DateTime API that was heavily influenced by Jodatime with the benefit that as it is in the standard library, it can be more heavily adopted by library-writers.
https://www.joda.org/joda-time/ https://www.baeldung.com/java-8-date-time-intro
Re: Jiff: Datetime library for Rust
#107While 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…
Burntsushi explains here in great detail the reasoning for not supporting leap seconds: https://github.com/BurntSushi/jiff/issues/7
Re: Jiff: Datetime library for Rust
#108While 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.
That doesn't change the situation of past leap seconds in any way, those still need to be accounted for.
Re: Jiff: Datetime library for Rust
#109While 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…
Burntsushi explains here in great detail the reasoning for not supporting leap seconds: https://github.com/BurntSushi/jiff/issues/7
Yes, that was what I was referring to with
> I appreciate that it was at least informed decision, and seems to have been tough call to make
but you are right, having that link here helps others.
Re: Jiff: Datetime library for Rust
#110A little off topic but does anyone know the purpose of dual licensing MIT and the UNLICENSE? It seems like the second should already allow anyone to do whatever they want…
Should have used GPL or at least LGPL