Set the timer display to four decimals and start it. It reads 00:04.2137. What is that final 7 doing there?
Three statements about it are all true, and they do not agree with each other. The display shows four decimal digits — a real ten-thousandths column. Our About page is not a specification, but it does say “Precise timing with millisecond accuracy”. And our Terms of Service say we “do not guarantee precise timing for professional or critical applications”.
This post exists because all three sentences are in the product, and the honest answer to what the fourth digit means has to reconcile them. The short version: the digit is real, it is a property of how time is displayed, and it is not — by itself — a claim about how correct the measurement is. Those are three different things, and metrology has separate names for each.
Where the digit comes from
Nothing in the display is fabricated. Here is the chain, all of it verifiable in the app’s source.
When you press start, the app records the phone’s clock reading. When you press stop — or lap, or pause — it reads the clock again and subtracts. That difference is the elapsed time. The clock readings come from the operating system, and on every platform the app ships on, the system call the Dart runtime uses — gettimeofday or its equivalent — carries microseconds, not just milliseconds. The subtraction preserves them: Dart’s DateTime.difference() returns a microsecond count, straight from one microsecond timestamp minus another.
The formatter then does simple arithmetic. Four decimals means ten-thousandths of a second, so it takes the microseconds and divides by a hundred. If the difference between the two clock readings was 4,213,700 microseconds, the display shows .2137. The digit is not generated, padded or estimated. It is the last honest digit of a subtraction.
The same is true after you close the app. Laps and events are stored as microsecond integers, and the export renders those stored values — the CSV’s seconds column is the stored microseconds divided by a million, rounded to your chosen precision. The export digits are not computed differently from the display digits. There is one measurement, stored once, shown at whatever resolution you pick.
Our own support guide says it in one line: “Times are stored in microseconds. You choose how many decimal places to display, up to four.”
Three words that are not synonyms
So the digit is real. The question is what it means, and here the science of measurement is blunt: resolution, precision and accuracy are three different properties, and displaying more of the first says nothing about the other two.
Resolution is the smallest difference a display can show. Ours shows a hundred microseconds.
Accuracy is closeness to the true value. The international vocabulary of metrology — the VIM, the reference document measurement scientists use — defines it as “closeness of agreement between a measured quantity value and a true quantity value”. It is a property of the whole measurement, not of the digits.
Precision, in the standards’ sense, is closeness of agreement between repeated measurements. A clock that is wrong by exactly 41 seconds every single day is extremely precise and inaccurate. The VIM even carries an explicit warning that “measurement precision” is “erroneously used to mean measurement accuracy” — the confusion is common enough that the reference document names it.
NIST, the United States’ measurement standards institute, takes the last step: accuracy is a qualitative concept, and numbers should not be attached to it. In NIST’s guidance on expressing uncertainty, you may write “the standard uncertainty is 2 µΩ” but not “the accuracy is 2 µΩ”. So the sentence “this stopwatch is accurate to 0.1 milliseconds” is not modest — it is malformed. The fourth digit gives us resolution. Any accuracy statement would need an error bound, measured against a reference, under stated conditions.
We have not measured one. Nothing in the app’s timing path performs calibration, averaging, or any characterisation of timing error — the elapsed value is raw clock arithmetic, rendered directly. We are not hiding a number we know; the number was never taken.
The finding we owe you
Since this is a post about our own digits, here are two things in the product that deserve the admission.
The code contains a comment — “Use Dart’s Stopwatch for microsecond-precision timing” — above a monotonic timer object. That comment is misleading, and we can say so because the objects it describes are never read for time. All timing comes from the wall-clock arithmetic described above; the code’s own comments elsewhere concede the monotonic timers are “no longer used for time calculation”. The comment promises an instrument the app does not consult. It stays until it is fixed, but no post about our decimals should lean on it.
The second is the copy. The App Store description promises what the code cannot show — “Millisecond accuracy for professional timing needs” — while the Terms decline to guarantee precise timing for professional or critical applications. The code contains no accuracy measurement that could referee between them. Where a vendor’s copy and a vendor’s code disagree, the honest reading is the code — and this is our product, so the rule applies to us first. The About page’s phrase is aspiration; the Terms’ disclaimer is the contract; the digits on screen are resolution, fully delivered, promising nothing beyond themselves.
The price of reading the wall clock
Why does the app read the phone’s wall clock instead of a self-contained timer? Because the wall clock is what survives. An app-level timer stops when the system suspends the app; the phone’s clock does not. Reading the wall clock at start and stop is why an interval keeps its value through backgrounding, process death and state restores.
The design has a price, and we have documented it before. The elapsed value is a difference of two wall-clock readings with no clamping, so if the phone’s clock itself is corrected while you are timing, the reading moves by exactly that amount, instantly. And time sync protocols do step clocks, in jumps above 125 milliseconds. The app does not detect or correct a clock step; the interval follows the phone’s clock wherever it goes. If you need a measurement that cannot be touched by a sync correction, the design story is laid out here.
That is the trade: a stopwatch that keeps running through anything the phone does, at the cost of trusting the phone’s clock completely.
What the setting actually sets
The Decimal Precision control in settings goes from zero to four decimals. It changes what you see — and what the export writes — and nothing else. Time is not measured in two-decimal mode and four-decimal mode; it is measured once, in microseconds, and displayed at your chosen granularity. Choosing two does not make the timing coarser. Choosing four does not make it finer. Both show the same stored number, rounded differently.
That is the whole answer to the opening question. The 7 in 00:04.2137 is the ten-thousandths digit of a real microsecond difference between two readings of your phone’s clock. It is resolution, delivered honestly. It is not a promise of accuracy, because a digits-count cannot be one — and because no measurement backing such a promise exists in this app.
When it matters — race timing, experiments, anything where a hundred microseconds could change a conclusion — the right instrument is a purpose-built timer checked against a reference. When what you need is a faithful, durable, plainly displayed interval, that is what TiCaNo Stopwatch is built to do, and the fourth decimal is part of doing it plainly.
Sources
Claims about the app are verified against the shipped TiCaNo Stopwatch v1.6.2 — the build currently in both app stores.
- JCGM 200:2012 (VIM3), entry 2.13 — measurement accuracy — BIPM, the definition accuracy is held to
- JCGM 200:2012 (VIM3), entry 2.15 — measurement precision — BIPM, including NOTE 4’s warning against using “precision” to mean “accuracy”
- NIST Technical Note 1297 — Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results — on accuracy being qualitative and numbers belonging to uncertainty
- RFC 5905 — Network Time Protocol Version 4 — IETF, the 125 ms step threshold