Adding the 43 per-segment times lands on 12616 seconds while the total cell reads 12600
Fill in distance as 42.195, fill in total time as 3:30:00, leave segment length at 1 km and increment at 0, and the page renders a 43-row segment table. Add up the 43 display values in the per-segment column one by one and they total 12616 seconds, 16 more than the 12600 shown in the same frame's total-time cell. And yet the last row of the accumulated column still reads 3:30:00, because it was never rounded segment by segment. Two columns stand side by side in one table: one closes on the total, the other is 16 seconds off.
All 43 boundaries line up with 42.195. What differs is the ruler: every row's own time is rounded to a whole second before display, and once 43 whole-second integers sit side by side they no longer sum to that same whole-second total.
The half-marathon sample makes the same split harder to miss. The first three per-segment cells of row 3 read 26:15 plus 25:25 plus 24:35, which adds up to 1:16:15, while the accumulated cell of the very same row reads 1:16:14, and that 1-second gap sits plainly between two adjacent columns of the same row.
Change the segment length and the drift changes sign too
Hold distance and total time fixed and turn only the segment-length knob: the signed gap flips between positive and negative, and sometimes lands exactly on zero.
| Scenario | Segment | Rows | Per-row sum | Against the total |
|---|---|---|---|---|
| 42.195 / 3:30:00 | 1 | 43 | 12616 seconds | 16 seconds over |
| Same as above | 2 | 22 | 12595 seconds | 5 seconds under |
| Same as above | 5 | 9 | 12599 seconds | 1 second under |
| Same as above | 0.3 | 141 | 12658 seconds | 58 seconds over |
| 21.0975 / 1:45:00 | 1 | 22 | 6308 seconds | 8 seconds over |
| 26.2188 miles | 1 | Not retrieved | Not retrieved | 11 seconds over |
| 10 km / 1 hour | 1 | Not retrieved | 360 whole seconds per row | 0 seconds off |
Every cell in one frame measures with its own ruler
The pace cell rounds to whole seconds; the total-time string, the long-format string and the signed-difference string each go through their own pass of that same rounding. The km/h cell, the mile/h cell and the m/s cell are stored as two-decimal values scaled by 100 and divided by 100; the distance write-back box keeps four decimals scaled by 10000 and divided by 10000; the start and end columns of the segment table keep one decimal while the accumulated distance keeps three; and the segment-count row applies Math.floor with an extra 1e-9 bolted on. None of these rulers close on one another. The plainest proof is that reconstructing any displayed value from the other displayed values on the same frame does not reproduce that same value.
The true pace 298.61357980803410328 seconds renders on screen as 4:59. Take that 4:59 back as 299 seconds and the reverse-engineered speed is 12.04, but the speed cell on the page shows 12.06 km/h. Reverse the same pace into metres per second and you get 3.34, while the m/s cell shows 3.35. The 400 metre lap display reads 1:59; multiply by 2.5 and that is 297.5 seconds per kilometre, and 1.5 seconds per kilometre off the pace cell's own 299 seconds. Each cell is right inside its own layer. The six cells on the running pace calculator are all describing the same underlying number of seconds.
Read Figure 1 top to bottom and you have the full list of rulers: the same seconds rendered five different ways, as whole integers, as two decimals, as four decimals, as one decimal, and as three decimals, none of them the exact value underneath.
Delete the 1e-9 on its own and none of the 108 combinations shift
The epsilon at the tail of the segment-count row looks like the natural culprit behind segment drift. Copy the file with every one of the remaining 416 rows untouched and open a second context with only that epsilon stripped out, then sweep 108 combinations of distance and segment length: the segment-count difference is 0 in every case, the largest last-segment length difference is 4.86e-15, the last-segment cumulative endpoint differs by 7.1e-15, and the segment description strings match byte for byte. What actually closes the last segment is the remainder branch on the very next line, which treats a leftover shorter than the segment length multiplied by 1e-6 as no remainder at all. So this epsilon only ever rewrites the 14th significant digit; not one visible display shifts, and those 16 seconds have nothing to do with it.
Mile-mode write-back keeps four decimals, so converting back does not return the original
The unit constant RP_MILE is 1.609344. Switching 42.195 km over to mile mode rewrites the distance box as 26.2188, while the true value underneath is 26.218757456454305554 - the four-decimal layer rounds it up rather than truncating it short. Now take the 26.2188 sitting in the box, treat it as miles and convert back to km; what comes out is 42.195068467200002260, and a single round trip has drifted by 0.0000685 km. Per-mile pace splits along the same fault line: divide directly by the mile distance and you get 480.57197298258091678 seconds, but multiply the km pace by the constant and you get 480.57197298258085993 seconds, a difference of 5.68e-14 - and yet both modes still render as 8:01 on screen.
Refill the on-screen 4:59 and the finish time becomes 3:30:16
Type 3, 30, 0 into the time boxes first: total time reads 12600 seconds and the pace cell shows 4:59. Now take that display value back and commit 4 minutes and 59 seconds into the pace box. The page multiplies 299 by 42.195, arrives at 12616.305 seconds, and the total-time cell now shows 3:30:16. One round trip costs 16 seconds - which is the exact same drift you get by summing the 43 rows of the segment table and finding 16 seconds extra. Multiplying a whole-second pace back against a distance that carries four decimals simply does not land on the original whole second. The target row that says 3:30:00 corresponds to 4:59 also differs by 16.305 seconds once you multiply the right column back through, so left and right columns of the same table refuse to recognise each other. Whatever the two strings differ by, you can subtract them second by second on the time add and subtract calculator.
Figure 2 lays the same fact out four times over: the 16 seconds added once, subtracted back, still come out as 16 seconds, no matter which side of the round trip you start on.
One finish line, three tables, three algorithms
Inside this single 42.195 km frame the finish is computed three times over. Stepping segment by segment and evaluating distance times mean pace both land on 12599.999999999998 seconds; the target 3:30:00 is exactly 12600 seconds; the display layer writes all three of them as 3:30:00, and the first two carry a floating-point tail of 2e-12. Row counts follow their own rulers as well: the milestone km table has 12 rows, the milestone mile table has 11 rows, a half-marathon distance gets only 7 rows, the prediction table drops the entry that coincides with the current distance and keeps 7 rows, the target table lists 8 tiers for the full marathon, and non-standard distances produce 6 rows via six multipliers. What happens in the space between one segment and the next is a question our segment pace table article answers; this post stays on the roundings and the segment ledger.
Q: Were these numbers measured inside the browser?
No. The template is 609 lines and 27084 bytes; the 417 script-block lines were compared line by line with 0 misses; the 42 top-level functions inside that block were read back with toString and matched the original text character for character, 42/42, with no rewrites and no bug fixes anywhere in the loop. Every reading came from Node's bare vm. Layout, scrollbar behaviour and total elapsed time were never measured and are outside the scope of this post.
Q: The segment rows sum to a number that does not match; is the page computing wrong?
Each cell is correct inside its own layer. What does not close is the space between layers: the per-segment rounded column and the un-rounded accumulated column stand side by side, and those 16 seconds fall squarely in the gap between them.
Q: What happens if 1e400 is typed into the distance box?
It parses into 1400 and gets written silently into the distance field, the hint line stays empty, and there is no gate on the large-distance side at all. The segment-row count for that scenario could not be pulled back by the probe, because the output was truncated; it was never measured directly.