A timer that never ticks

The timer Untimer replaces was a browser tab. It worked well until you touched it. Refresh the page and the session was gone. Leave the page and come back, gone. Open it on a phone, and the phone put the tab to sleep and the countdown stopped. The founder used that timer every day for years and lived with all three problems.

The cause was where the time lived. That timer kept “seconds remaining” in the memory of the page and counted it down in a loop. That is the obvious way to build a timer, and it breaks easily. Page memory disappears. Loops in background tabs get slowed down. The computer’s clock can be changed by the person using it, by the operating system, or by a laptop lid closing for an hour.

Untimer is built the other way round. This article explains what that means for you.

A session is a moment

When you let go of the glass, the server writes down one fact: this session ends at a particular instant. 10:25:00 and some milliseconds, in the server’s own time. It writes a few other facts beside it: when it started, what it is for if you said, how long it was planned to be. Then it does nothing. It does not count. There is no process anywhere that ticks once a second for you.

Every screen that shows the countdown does the same small sum: the end moment, minus the time now, drawn as minutes and seconds. It does that sum fresh on every repaint and never stores the answer. There is no “seconds remaining” anywhere. There is a moment, and a distance to it.

This is why a refresh changes nothing. The page loads, asks the server what is happening, is told the end moment, and draws the distance. It was never holding anything it could lose.

Your clock is not trusted

If the screen used your computer’s clock, a clock that runs a minute fast would show a session a minute short, and a clock that jumped during a sync would make the sand lurch. So every answer from the server carries the server’s own time, and the app anchors to that. It notes the server’s time and its own monotonic counter at the moment the answer arrived, and from then on it measures elapsed time from that counter, which nothing on your machine can move. The wall clock can be wrong by an hour and the sand is still right.

When a laptop wakes from sleep the counter is stale, so the app asks again. It also asks again when the tab becomes visible, when the window gets focus, and when the network comes back. Each of those is one small request, and each one re anchors the clock. Using the app keeps it right.

One session, and the database makes sure

You cannot have two sessions running. The database will not store a second live session for the same person, because a unique rule on the table forbids it. If your phone and your laptop ever race to start one, exactly one wins and the other is told what is already running and adopts it. Two devices cannot disagree about which session is live, because there is nowhere for a disagreement to be written.

Every change you make carries a small random ticket as well. If your connection drops halfway through pressing Reset and the app retries, the server recognises the ticket and does not reset twice. Retrying is always safe, and you will never notice it happened.

It finishes on its own

What happens when the session reaches zero and nobody is looking? The tab is closed, the laptop is shut, the phone is in a bag.

Nothing needs to happen, because the end moment is already written down. The next time anything asks the server anything, it first looks for sessions whose end moment has passed and records them as complete, ended at the moment they were due. A session that finished at 10:25 while you were in a meeting is recorded as finished at 10:25 when you open the app at 14:00. Your history is correct without a single device having been awake for it.

The app never writes a completion of its own. When the sand runs out on screen, it asks the server to confirm, and the server hands back the record it just wrote. The line in the box at the end of a session comes from that record.

The bell is placed on the clock

There is one more place a timer usually counts, and it is the sound at the end. The obvious way is to check every second whether it is time to ring. In a tab you have hidden behind your work, browsers slow those checks to once a second, and after a few minutes to once a minute. A bell that rings a minute late is a bell you stop trusting.

So Untimer does not check. The browser’s audio system keeps its own clock, and that clock keeps going in a hidden tab. When a session starts, the sound is placed on that clock at the exact moment the session ends and then left alone. Stopping takes it back. Resetting places it again. When the moment arrives it sounds, whatever the tab is doing.

There is one limit, and it is the browser’s rule: a page will not make a sound until you have touched it at least once. A page refreshed mid session has to be clicked or typed in before the bell can be placed. After that it is exact.

What this lets Untimer promise

Start a session at your desk and open the app on your phone: the same sand, at the same place. Refresh a hundred times. Close the tab and open it an hour later and find the session completed at the minute it was due. Let the laptop sleep. Let the clock be wrong.

Ten years of sessions will not slow it down either. No screen ever downloads your whole history. Your days are read one page at a time, the insights come from daily totals kept as each session ends, and the milestones are checked where a session ends. The timer the founder replaced did the opposite, and it got slower every month.

None of this is visible, and that is the point. A timer that never loses you is a timer you stop thinking about, so you can think about something else.