# When are folks removing \`Time.monotonic\` usage from their shards?
**URL:** https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691
**Category:** Help & Support
**Created:** [February 4, 2026, 3:59am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691 "2026-02-04T03:59:57Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@jgaskins](https://forum.crystal-lang.org/u/jgaskins)
#### Post date: [February 4, 2026, 3:59am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/1 "2026-02-04T03:59:57Z")
The new [`Time::Instant`](https://crystal-lang.org/api/1.19.1/Time/Instant.html) in 1.19 is great. I mainly used `Time.monotonic` to measure how long some operation took and `Time::Instant#elapsed` is perfect for that.
What _isn’t_ great is the long list of deprecation warnings when running specs in some of my shards. Updating apps is fine because we control which version of Crystal they use. That’s not true of shards, though. Updating those shards to use `Time.instant` may not be feasible if someone’s still using it on Crystal 1.18 or earlier.
How are folks dealing with this?
---
### Author:  [@omarluq](https://forum.crystal-lang.org/u/omarluq)
#### Post date: [February 4, 2026, 5:08am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/2 "2026-02-04T05:08:00Z")
I ended up making a [small module](https://github.com/omarluq/termisu/blob/main/src/termisu/time_compat.cr) that provides a unified interface based on the Crystal version at compile time. Nothing fancy but it does the job lulz!
---
### Author:  [@ralsina](https://forum.crystal-lang.org/u/ralsina)
#### Post date: [February 4, 2026, 10:59am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/3 "2026-02-04T10:59:15Z")
It’s a bit annoying that it went from not existing to making the alternative deprecated in a single release. So now we have to choose between saying “this only works in crystal \>1.19” or getting a ton of deprecation notices for code that works fine.
---
### Author:  [@straight-shoota](https://forum.crystal-lang.org/u/straight-shoota)
#### Post date: [February 4, 2026, 12:11pm UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/4 "2026-02-04T12:11:34Z")
I believe the annotation reporting may be a bit too noisy.
The intention of these annotations is primarily to avoid using deprecated features in _new_ code (unless it needs to be compatible with older versions), and maybe start to migrate old code. But a deprecation notice is not intended as an immediate call to action that you need to replace it at once.
You can also entirely ignore warnings for library code (`--exclude-warnings=./lib`).
---
### Author:  [@ysbaddaden](https://forum.crystal-lang.org/u/ysbaddaden)
#### Post date: [February 5, 2026, 10:58am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/5 "2026-02-05T10:58:46Z")
I like how Elixir deals with deprecation in its stdlib:
1. _soft_ deprecation in version X:
2. _hard_ deprecation in version X+n:
It gives some time to adapt software without being annoyed.
For example libraries can wait for the hard deprecation and not care about backward compatibility with Elixir \< X yet still be compatible with the latest n releases.
---
### Author:  [@jgaskins](https://forum.crystal-lang.org/u/jgaskins)
#### Post date: [February 6, 2026, 2:21am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/6 "2026-02-06T02:21:54Z")
The way this happened might’ve been more palatable for methods with fewer dependents than `Time.monotonic`, to be clear. That method being such a lynchpin for measuring how long something takes in places that `Time.measure` might not be suitable due to block semantics made it a bit of a perfect storm for a wall of deprecation warnings.
Also, periodic reminder that the `@[Deprecation]` annotation is honestly amazing. The ability to show deprecation warnings at build time and in docs with a single line of code is amazing. I tried to do something similar in Ruby 15-ish years ago and it was a gross hack.
---
### Author:  [@jgaskins](https://forum.crystal-lang.org/u/jgaskins)
#### Post date: [February 18, 2026, 4:40am UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/7 "2026-02-18T04:40:33Z")
Following up here, @akadusei came up with a great way to handle this in my `redis` shard. It’s similar to @omarluq’s approach but we didn’t end up needing the type alias.
>
>
> \`Time.monotonic\` is deprecated since Crystal v1.19.
---
### Author:  [@Kritoke](https://forum.crystal-lang.org/u/Kritoke)
#### Post date: [April 19, 2026, 12:52pm UTC](https://forum.crystal-lang.org/t/when-are-folks-removing-time-monotonic-usage-from-their-shards/8691/8 "2026-04-19T12:52:29Z")
I was wondering this as well. I have a bunch of libraries and an app or two that still are using 1.18.2 mostly since FreeBSD didn’t have 1.19.1 until recently. Once we start moving to it, it potentially could break those that still use 1.18.2 if the other libraries can’t handle the Time.Instant. I guess with ai it’s easier to fork and update things, but could get annoying depending on what all things you have to mess with.
-Matt