Why does a timer force you to decide when a task is finished?

You are writing a report. At some point you stop typing and open your email, just for a second, to check something related to the report. Then you answer the email properly. Then you are back in the document, except now you are also thinking about what you just answered. Somewhere in the middle of this the timer is still running, attached to "writing report," and at some point you are going to have to press stop and, in doing so, decide exactly when the report-writing part of the last hour actually ended. It didn't end at a moment. It just gradually stopped being the only thing happening.

A timer needs an edge that most tasks do not have

Starting a timer is a small commitment, but stopping one is a bigger one, because stopping requires you to locate a precise second at which a task became finished — or at least paused cleanly enough to log. Plenty of work does have that kind of edge: a meeting ends when everyone leaves, a phone call ends when you hang up. But most of what fills an ordinary hour does not end that way. It thins out, gets interrupted, drifts into something adjacent, or simply keeps going in the background of your attention while something else takes the foreground. A timer does not have a setting for any of that. It only has a button that says the task is over now, and it needs you to press it at some specific instant whether or not the task actually agrees.

What "stop" is really asking you to decide

Pressing stop looks like a small, mechanical action, but underneath it is a judgment call: was that email a break from the report, or part of it, since it was about the report? Did the report-writing actually end when you opened your inbox, or only once you gave up on getting back to it tonight? A timer cannot answer this for you — it just waits, running, until you supply an answer it can record as a number. So you supply one, usually arbitrarily, usually a little later than you meant to, and the number that gets saved is less a measurement of the task than a record of when you finally got around to making a decision about it.

Both ways of resolving it are wrong in a different way

Stop the timer the moment your attention first wavers, and the recorded stretch is shorter than the task actually took, because you were still circling back to it between other things for another twenty minutes. Let the timer keep running through the email and the drifting and the second cup of coffee, and the recorded stretch is now padded with everything that happened to occur while the task was merely open on your screen, not actively receiving your attention. Neither number is dishonest exactly — both are answers to a real question — but neither one is a clean account of what the hour actually contained, because the hour never had the single edge the timer needed from it.

The decision gets postponed, which is its own kind of friction

Because ending a task cleanly is often harder than it sounds, a running timer has a way of getting deferred rather than stopped. It stays open through the next thing and the thing after that, not because anyone forgot about it, but because closing it properly means stopping to work out exactly when the report stopped being the report — and that small piece of accounting is more annoying than just leaving the timer running and dealing with it later. Later usually means at the end of the day, trying to reconstruct from memory where one task actually gave way to the next, which is precisely the kind of retroactive guessing a timer was supposed to make unnecessary in the first place.

A log never asks where the edge is

A line in a log does not need a beginning and an end negotiated in advance. It needs a moment — this is what I was doing, roughly now — and nothing about writing it down requires deciding whether the task before it has technically concluded. You can write "working on the report" at 2:00 and "answered an email about the report" at 2:20 and "back on the report, distracted" at 2:35, and all three are true, complete, and require no arbitration about where one stopped and the next began. Nothing is running in the background demanding a verdict. There is simply a sequence of moments, each described as it actually was, with the messy overlap between them left exactly as messy as it really is.

Write the moment, not the boundary. "Working on the report, half-distracted by an email thread" is a complete entry. It does not need to resolve into a clean before-and-after.
Let one entry cover a blurry stretch. If an hour was mostly one thing with some drift at the edges, a single honest line about the hour is more accurate than a falsely precise start and stop time either side of it.
Log the interruption as its own line if it mattered. "Paused to answer an email, longer than expected" is worth writing on its own — not as a subtraction from the task it interrupted, just as a thing that also happened.
Do not go back and tidy the timeline. The temptation, once a day is over, is to smooth everything into neat blocks. The blur is usually the truer record; smoothing it out is where the guessing creeps back in.

What this saves you from

None of this is really about saving a few seconds of button-pressing. It is about removing a decision that most tasks were never going to give you a clean answer to, asked at a moment when you have the least patience to work it out — right in the middle of doing the next thing. A record built from moments rather than intervals does not need that decision made even once, which turns out to remove a surprising amount of the low-grade friction that makes a timer feel like work on top of the work.

TimeMap records a moment and a colour, not a start time and an end time. There is nothing to stop, so there is nothing to negotiate about when a task really finished — you write what you were doing when you thought to write it, and the next entry, whenever it comes, does not owe the last one an exact handoff.

The next time a timer sits open longer than it should because stopping it means making a call you would rather not make, it is worth asking whether the task ever really had the kind of edge a timer assumes every task has. Most of the time it did not, and a line describing what was actually happening would have been both easier to write and closer to true.