This repo is a small thought experiment around using time itself as a way to sort numbers.
The idea is not original. I saw a TikTok where someone was talking about bad technical interviews they had seen. One candidate was asked to sort a list of numbers, so he added a wait based on each number and printed the values as the waits finished. She said she could not hire him.
I thought the solution was secretly kind of genius, and I could not stop thinking about it. About a year later, I finally decided to play around with the idea.
The basic thought is simple: time is already ordered. If each number is scheduled to run after a delay based on its value, the smaller numbers should finish first.
That immediately creates a few problems:
- Large numbers could require an unreasonable amount of waiting.
- Dividing the values reduces the wait, but also reduces the distance between nearby event times.
- Real clocks and operating-system schedulers have limited accuracy, so two close values may fire at effectively the same time.
- A scheduler may already use an ordered data structure internally, meaning some of the sorting work is just being moved somewhere else.
To explore the accuracy problem, this implementation uses a virtual clock with a fixed number of distinguishable time slots.
Numbers that land in different slots are ordered during the first stage. Numbers that collide in the same slot are placed into a smaller group, the clock is reset, and that group is processed again using a narrower numeric range.
This turns the idea into something closer to a temporal bucket or radix sort. Each stage reveals a little more of the ordering until the values can be separated.
This is not intended to replace real sorting algorithms. It is just me following an idea, testing where it breaks, and trying to better understand the difference between computational work, elapsed time, clock precision, and the hidden work performed by a scheduler.