just like we assume that developers can be educated to use bcrypt or argon2i to hash passwords, or use Random::Secure to generate tokens.

I just learnt it using Crystal, so Crystal made me more educated 👨‍🎓

Could we just get a Time.monotonic returning a Time::Span or even a Float64 of seconds?
https://docs.python.org/3/library/time.html#time.monotonic

...Because I think that there are many more legitimate use cases for globally monotonic time than just measuring the time difference. Besides, we already have many benchmarking tools.
I do realize that you could keep an instance of this struct and use it as an absolute reference, but that just seems like unnecessary trouble.

But if you do still want to go for this kind of API, please add an atomic restart feature, to avoid another bad practice.
To repeat something at an interval, people might get the elapsed time, reset the clock (and repeat), ignoring that some time passes in between those two actions.
https://www.sfml-dev.org/tutorials/2.4/system-time.php#measuring-time

I just gave this more thought and realized that the use case of an absolute time reference is not covered either. For example, I might want to store the creation time for each of my objects and then order them by it. There's simply no way to do this with this kind of API even if I stored this object because it produces a different value every time its method is called.

The underlying implementation is fine and there's no reason whatsoever to hide that absolute number. Just make a method returning a Time::Span and define it as returning a non-decreasing amount of time that has passed since a constant but unknown moment in the past. No need for any new types; Time::Span already supports all the operations you might want to do with this data. And don't tell me that a separate type that happens to have all the same fields makes more sense, because this is not a coincidence.

People are indeed very happy to use the subtraction idiom. It's not only popular but also very intuitive. Just explain that they want to use it on something other than Time.now.

All in all, I cannot support an API that adds a new type and 8 new methods but covers only a small fraction of use cases that one simple and familiar method can cover. So, 👎 from me.

Since monotonic clocks only mean something when compared, I only look for measuring time here —the obvious use case. Do you have other use cases that involve using raw monotonic clocks (e.g. as a float)?

I guess a #restart method is fine, but if measuring different times I feel we can just call Time.measure {} multiple times.

Maybe there could be a Time.start to avoid the Time::Measure.new which ain't really pretty, and somewhat hide this struct:

clock = Time.start
clock.elapsed
clock.restart
clock.elapsed?(5.seconds)

Maybe just Time.measure without a block instead of Time.start?

@oprypin The problem with reusing an existing concept like Time::Span or Float64 is that it looses meaning expressed in the type.
A measurement from a monotonic clock is just an arbitrary amount of time and should not be misinterpreted as a Time::Span (because the reference is unknown) or even an ordinary number.
If you want to order objects based on creation time, you measure the time from a single Time::Measure instance when an instance is created. Then you can compare these time spans (optionally converted to float if you like). Time::Measure does not represent a point in time like Time does, but a source and reference point for instances which are expressed as a time span elapsed from the reference point.

@straight-shoota, I have nothing to add, because my comment already addresses all you said.

just like we assume that developers can be educated to use bcrypt or argon2i to hash passwords, or use Random::Secure to generate tokens.

Except there's little we as language authors can do to solve these, apart from provide easy to use classes, and document that they should be used for passwords. This is an opportunity where we can do something, and so I think we should do it.

And no, go has the exact same backwards compatiability constrains we have here (none for adding an API). They could have introduced a new monotonic time API just like this PR does, and that wouldn't have "broken backwards compatability". We too have plenty of shards which use Time.now - Time.now and I'm sure - regardless of this change - there will continue to be in the future. Go's decision was inspired: fix this for everyone automatically with a small addition of overhead. If people really care about Time.now performance we can introduce named args to fill out one of the other type of time.

These kind of time bugs are special, because they only really happen on leap seconds, which occur very rarely. So it's unlikely that bugs will be found until they're run in production unless he application is fuzzed for time shifts which is very unlikely and unweildy.

@oprypin I missed your previous comment, and ... I believe you're totally right; there can be use cases to get the monotonic clock and not necessarily measure elapsed time.

The go-like alternative of mixing a monotonic and realtime clocks in a single Time.now doesn't solve this case either —and IMHO only makes internal implementation even more complex, as if dealing with timezones and DST offsets wasn't a daunting task, already.

What about simply having Time.monotonic : Time::Span and that's it? Maybe add the Time.measure(&block) : Time::Span sugar to return an elapsed time, and nothing more —for the time being.

It would be simple enough, doesn't create new types, and would be future-proof to whether we merge realtime+monotonic clocks in Time.now (or not) and it allows to access the always increasing monotonic clock for special purposes. WDYT?

What about simply having Time.monotonic : Time::Span

Well I also have said basically that so I definitely agree

I must say, I was actually surprised to see Time::Measure in this PR.