In the discussion of RFC0014 it became apparent that the Time::Span type can lead to confusion. Its primary purpose is to represent a duration of time. But we also use it for a reading of the monotonic clock ( Time.monotonic ). This makes some sense because the monotonic clock is just the time elapsed…

Clocks might be interesting to have. We could have clock-aware sleeps and timeouts, like wait until 5 pm (real time) or wait until 10 monotonic seconds have passed.

Yes please, it’s because of this I have to do some silly things to convert the Time::Span to an actual Time: athena/src/components/clock/src/monotonic.cr at master · athena-framework/athena · GitHub .

I’d actually just consider a type for a clock reading, i.e. a representation for an instant in the monotonic clock’s timeline. There’s no need for a dedicated type for a monotonic clock. We just need a single class method to get the current instant. That’s it. Throwing together monotonic time and …

Oh sorry, I wasn’t suggesting we add a dedicated type for diff kinds of clocks. But instead having it not return Time::Span could make it so it’s easier to resolve Time.montonic to a wallclock time if so desired (instead of the silly nanosecond math stuff I have to do currenlty); maybe via some #to_…

[image] straight-shoota: A monotonic clock reading represents an absolute instant I’ve never inspected the value of the return value of Time.monotonic until right this moment. I knew it was a Time::Span but always assumed it was the duration since the process started. I honestly had no idea w…

I think Time::Instant is a better name and could be used instead of Time::Monotonic, you know it’s a good name when you use it to describe what it means. [image] straight-shoota: a Time::Monotonic (working title) argument represents an absolute instant.

I like the argument. But I fear this name would be too imprecise and create a new ambiguity: Time also represents an instant, just on a different timeline. Time::MonotonicInstant would be sufficiently specific, but I figure it could just be shortened to Time::Monotonic. Perhaps Time::Tick could al…

I split off the discussion thread about sleep with a wall clock . It’s independent of the type for monotonic clock readings. These two partial quotes are relevant for this thread, though: [image] Generalize `#sleep` for monotonic and wall clock Maybe there could be a Time::Instant type to repres…

Having the result of 10.seconds and Time.monotonic be separate types is a very good idea; it’s something that has caused me accidental confusion at times. (Not because I misunderstood, but because I was sleepy and it compiled, so I assumed I hadn’t made any major mistakes… it took me a while to find…

every time I think of timers for loops I always go back to this blog post. Timeouts and cancellation for humans — njs blog . I think we should abstract timeout and other reasons to cancel into a cancellation token - there are other reasons to abort async code besides timeouts

Ambiguous use of `Time::Span` for duration and monotonic clock

Crystal Contrib

Topic		Replies	Views
Generalize `#sleep` for monotonic and wall clock Crystal Contrib	11	319	September 2, 2025
Am I getting the delta time correctly? Help & Support	5	672	October 15, 2019
Use Time.monotonic to measure time in spawn not work as expected Help & Support	1	302	May 10, 2023
Time ergonomics Crystal Contrib	13	396	September 3, 2024
Exposing the LibC time function calls Crystal Contrib	1	495	October 10, 2019

Ambiguous use of `Time::Span` for duration and monotonic clock

Related topics