Live data from Hacker News

Jiff: Datetime library for Rust

github.com

91–100 of 249 posts

Re: Jiff: Datetime library for Rust

#91
post #73

Earlier quoted context omitted.

> The freedom to deny the freedom of another person is not a freedom worth discussing. If that was true, you wouldn't be doing just that.

So, to be clear, your argument is that the freedom to deny the freedom of other people is a freedom that should be protected? How do you deal with issues like slavery and, in particular, its abolishment?

usea's argument is clearly not that but only that you can't literally think something is "not worth discussing" while you are actually discussing it.

The person who was explicitly defending non-GPL licences was rahkiin. I don't know how they'd respond to your challenge, but here is how I would:

"The freedom to deny the freedom of other people" is impossibly vague, because "the freedom of other people" can mean zillions of things. It's also confusing to talk about since we have two separate freedoms here, so let's talk about the freedom(1) to deny the freedom(2) of other people.

Suppose we put "the freedom to kill other people" in the freedom(2) slot. Most of us think that isn't a freedom people are entitled to, so the freedom(1) to deny that particular freedom(2) would be a good thing.

Suppose we put "the freedom to breathe the air" in the freedom(2) slot. Most of us think that is a freedom people are entitled to, so the freedom(1) to deny that particular freedom(2) would be a bad thing.

In the present case, what goes in the freedom(2) slot is something more complicated and less clear-cut -- it isn't a Super-Obvious Fundamental Human Right like the right to go on breathing, but it also isn't a Right To Do Very Evil Things like the right to murder.

It's something like "the freedom to read and modify the source code of a particular piece of software". We demonstrably don't presently have that freedom as regards many widely-used pieces of software; the world's legal systems pretty much unanimously agree that if you put this in the freedom(2) slot then the freedom(1) to deny it is worth having.

Why? Well, the usual arguments would be (1) that creating something gives you some rights to limit what other people do with it, and (2) that giving creators some such rights is a good thing overall because it increases the incentives for people to create nice things.

Of course you might disagree! (And, also of course, even if you agree with #1 and #2 in the abstract you might think that "intellectual property" law as currently implemented across the world is a very bad way to get #1 and #2.) But I hope your reasons are a matter of thinking carefully about the tradeoffs involved, not just of saying "yay freedom" and therefore denying every instance of "it's good for X to have the freedom(1) to deny Y's freedom(2) to do Z".

Not least because you literally can't consistently do so in every case -- if you say no one should ever have the freedom(1) to deny freedom(2) to others, whatever specific freedom(2) may be, then what you are calling for is precisely to deny that freedom(1) to others.

Re: Jiff: Datetime library for Rust

#92

I've been dealing with time and timezones for a long time, but this is the first time I have ever seen the "[Olson/Name]" suffix. Is that actually standard?

See for RFC 9557 document history: https://datatracker.ietf.org/doc/rfc9557/history/

I believe java.time also uses this syntax. I'm addition to Temporal.

It enables lossless round-trips of zoned datetimes. See: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...

Re: Jiff: Datetime library for Rust

#93
post #60

It's pronounced 'Giff' (with a hard 'G')

Non-native speaker here, what does "hard G" even mean? G as in "go", or G as in "gin"?

"G" as in "gadverdamme".

(Native speaker here - but of Dutch, the language known for its proper hard Gs. Unless you're from the South.)

Re: Jiff: Datetime library for Rust

#94
post #82
post #78

IMHO, 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…

What does this have to do with anything?

It's done in bad faith. Some are vehemently against Rust because of the "culture" around criticizing other languages' memory safety models, namely C/C++.

Re: Jiff: Datetime library for Rust

#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 personally appreciate correct results more.

From the wider ecosystem C++ std::chrono seems like the only one that shows some promise on this front. Last I checked the implementations were not there quite yet though, and the API definitely didn't seem all that pleasant. Maybe in couple of years we'll see how it'll work out.

Hifitime 4.0 seems like almost the only option at this point, and it is in early alpha still.

I recall using astropy at one point just for time calculations, but it is quite overkill solution.

The quest for perfect datetime lib (for any language) continues.

Re: Jiff: Datetime library for Rust

#96
post #4

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

I'm all for named parameters. C++ is sorely lacking that feature as well. Currently using vs code with C++, I like how it handles the missing language feature by adding a grayed out parameter name before the value for function calls and initializers. Maybe there is something like that for rust.

These are called "inlay hints" and exist for most editors/languages.

Re: Jiff: Datetime library for Rust

#98
post #49

The 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.)

Time library can be simple, it's just rust libraries tend to be philosophic for some reason, but it's only one of many design approaches.

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

Re: Jiff: Datetime library for Rust

#99

Earlier quoted context omitted.

Non-native speaker here, what does "hard G" even mean? G as in "go", or G as in "gin"?

"hard G" is the sound denoted "g" in IPA. The other "g" is "dʒ".

That is the convention in english as least. Other languages may differ.

Re: Jiff: Datetime library for Rust

#100

Earlier quoted context omitted.

"hard G" is the sound denoted "g" in IPA. The other "g" is "dʒ".

That is the convention in english as least. Other languages may differ.

Fortunately, since we are explicitly talking about English here, that convention is indeed the relevant one to use!
Post reply on HN