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

191–200 of 249 posts

Re: Jiff: Datetime library for Rust

#191

Post by jcgrillo »

burntsushi wrote: post #154
jcgrillo wrote: post #151

What does it mean for a Span to be negative? This is one thing I really like about Durations, they can't be negative and therefore match physical reality.

ISO 8601-2:2019 defines it as: negative duration: duration in the reverse direction to the proceeding time scale Matching "physical reality" is a non-goal. What's important is modeling the problem domain in a way that makes sense to programmers and helps them avoid mistakes. A negative span doesn't give you any extra expressivity that "subtract a span from a datetime" doesn't already give you. Both are a means to go…

Upon thinking about it a little more, I actually have a stronger opinion that it's probably not ideal to try to assign direction to durations themselves, and even then making them signed wouldn't be the best way. A duration is a scalar length measurement in the time axis. Those things are always positive, at least in our universe. I don't think we gain much by pretending otherwise, and I think we lose clarity.

Expressing a before/after relationship requires that we establish what is the anchor point. Is it the present time experienced in my reference frame? Is it unix epoch? Using a negative number to denote a disembodied "duration before" leaves me guessing about the anchor. In the case when we want to express the timestamp "3 days before/after time t0" I think it's probably best to say something like:

  t0.before(3.days()) // -> Timestamp
  t0.after(3.days())
This isn't a criticism of your library, it looks awesome and I'll definitely use it. I am fairly surprised that negative duration definition made it into the standard though.

Re: Jiff: Datetime library for Rust

#192

Post by wodenokoto »

TacticalCoder wrote: post #122
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…

I love burntsushi's ripgrep and certainly use it all the time, calling it directly from my beloved Emacs (and I do invoke it all the time). If was using ripgrep already years before Debian shipped rg natively. I was also using JodaTime back when some people still though Eclipse was better than IntelliJ IDEA. But there's nothing in that document that contradicts: "just represent duration as nanoseconds" . Users needs…

Calling sleep for 30 seconds really doesn’t have anything to do with dates or time of day.

Re: Jiff: Datetime library for Rust

#194

Post by drtgh »

aw1621107 wrote: post #184
drtgh wrote: post #104

Earlier quoted context omitted.

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

> 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. For references/documentation/tutorials I think the use of unwrap() and friends is a tradeoff. It (arguably) allows for more focused/self-contained examples that better showcase a particular aspect, though with the risk that a reader uses t…

> Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs"

It is more about always making the error reach the function that called the method/library (lost if one of the own dependencies of this library rise the panic [UB included] crashing the program), what allows the programmer to take the decision (and not to a deep dependency^5 ) about if to continue running the program, by taking alternative route, or not.

Re: Jiff: Datetime library for Rust

#195

Post by burntsushi »

jcgrillo wrote: post #191
burntsushi wrote: post #154

Earlier quoted context omitted.

ISO 8601-2:2019 defines it as: negative duration: duration in the reverse direction to the proceeding time scale Matching "physical reality" is a non-goal. What's important is modeling the problem domain in a way that makes sense to programmers and helps them avoid mistakes. A negative span doesn't give you any extra expressivity that "subtract a span from a datetime" doesn't already give you. Both are a means to go…

Upon thinking about it a little more, I actually have a stronger opinion that it's probably not ideal to try to assign direction to durations themselves, and even then making them signed wouldn't be the best way. A duration is a scalar length measurement in the time axis. Those things are always positive, at least in our universe. I don't think we gain much by pretending otherwise, and I think we lose clarity. Expres…

There are `checked_add` and `checked_sub`. But that shifts the "direction" of the span to the operation, which is a static property of your program, instead of being part of the value itself, which is a dynamic property of your program. I think this results in more annoying code where you just wind up carrying a sign around anyway.

There are also negative years, even though that doesn't really correspond to anything "real" either.

Here's the thread about signed durations for Temporal: https://github.com/tc39/proposal-temporal/issues/558

Apparently signed durations are a common feature in virtually every datetime library.

Re: Jiff: Datetime library for Rust

#196

Post by burntsushi »

drtgh wrote: post #194
aw1621107 wrote: post #184

Earlier quoted context omitted.

> 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. For references/documentation/tutorials I think the use of unwrap() and friends is a tradeoff. It (arguably) allows for more focused/self-contained examples that better showcase a particular aspect, though with the risk that a reader uses t…

> Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs" It is more about always making the error reach the function that called the method/library (lost if one of the own dependencies of this library rise the panic [UB included] crashing the program), what allows the programmer to take the decision (and not to a deep…

In other words, "every bug should be an error, and every failure should be an error." Except in order to make every bug be an error, you have to, well, know about every bug. And now all of your implementation details leak out into your public API errors.

Re: Jiff: Datetime library for Rust

#197

Post by DemocracyFTW2 »

Tigress8780 wrote: post #15
DemocracyFTW2 wrote: post #7

Earlier quoted context omitted.

I stumbled over use jiff::{Timestamp, ToSpan}; fn main() -> Result { let time: Timestamp = "2024-07-11T01:14:00Z".parse()?; I seem to remember Rust does that thing with interfaces instead of classes, is it that? How come I import a library and all of a sudden strings have a `parse()` method that despite its generic name results in a `Timestamp` object? or is it the left-hand side that determines which meaning `str.pa…

Rust will determine what `parse` does based on the inferred return type (which is being explicitly set to `Timestamp` here). This is possible when the return type has `FromStr` trait.

oh I see, almost what I anticipated

Re: Jiff: Datetime library for Rust

#198

Post by DemocracyFTW2 »

0x457 wrote: post #181
DemocracyFTW2 wrote: post #7

Earlier quoted context omitted.

I stumbled over use jiff::{Timestamp, ToSpan}; fn main() -> Result { let time: Timestamp = "2024-07-11T01:14:00Z".parse()?; I seem to remember Rust does that thing with interfaces instead of classes, is it that? How come I import a library and all of a sudden strings have a `parse()` method that despite its generic name results in a `Timestamp` object? or is it the left-hand side that determines which meaning `str.pa…

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

Re: Jiff: Datetime library for Rust

#199

Post by drtgh »

burntsushi wrote: post #196
drtgh wrote: post #194

Earlier quoted context omitted.

> Given how panics are intended to be used (handling unexpected state/precondition violations/etc.), it seems it seems akin to saying "just don't write bugs" It is more about always making the error reach the function that called the method/library (lost if one of the own dependencies of this library rise the panic [UB included] crashing the program), what allows the programmer to take the decision (and not to a deep…

In other words, "every bug should be an error, and every failure should be an error." Except in order to make every bug be an error, you have to, well, know about every bug. And now all of your implementation details leak out into your public API errors.

Not exactly. It is more like if a library is gonna crash the program (the deep dependencies used in that library triggered a panic on its own), just to let the programmer know it before happens; thus allowing the programmer to try alternatives for to avoid it, and if it's inexorable after those tries, for procedures for a controlled shutdown with proper protocols, actions, and so on.

I mean, as the crash is not exposed in the public API, given the things, I think it might not matter if this signal is exposed or not.

Re: Jiff: Datetime library for Rust

#200

Post by burntsushi »

drtgh wrote: post #199
burntsushi wrote: post #196

Earlier quoted context omitted.

In other words, "every bug should be an error, and every failure should be an error." Except in order to make every bug be an error, you have to, well, know about every bug. And now all of your implementation details leak out into your public API errors.

Not exactly. It is more like if a library is gonna crash the program (the deep dependencies used in that library triggered a panic on its own), just to let the programmer know it before happens; thus allowing the programmer to try alternatives for to avoid it, and if it's inexorable after those tries, for procedures for a controlled shutdown with proper protocols, actions, and so on. I mean, as the crash is not expos…

How do you let the programmer know? Through the public API...

Otherwise you have to catch panics via unwinding.

Post reply on HN