Open methodology
How TimerHub Keeps Time Accurately
Browser callbacks can slow down in a background tab. TimerHub does not treat those callbacks as the clock: countdowns use an absolute finish timestamp, and elapsed timers use an absolute start timestamp.
The timing model
- 1. Start: store the target as the current epoch time plus the chosen duration.
- 2. Update: derive remaining time from target minus current epoch time. Interval callbacks only decide how often the display repaints.
- 3. Recover: when a tab becomes visible or a sleeping device wakes, calculate from the same target again instead of replaying missed ticks.
- 4. Pause: preserve the derived remaining duration, then create a new target only when the timer resumes.
Reproducible checks
These deterministic cases run in the repository with npm test. They test the math independently from rendering speed.
| Scenario | Simulation | Expected |
|---|---|---|
| Background throttling | 60s countdown, 45.1s callback gap | 15s remaining |
| Pause and resume | Pause a 30s timer after 12.4s | 18s preserved |
| Six timers | 5s to 1h timers sampled together | All match target time |
| Device sleep | 1h elapsed-time jump | Full hour recovered |
| Daylight saving | Two instants across a clock change | 1h absolute duration |
| Denied alerts | Muted sound and denied notifications | Safe visual completion |
Honest limitations
- A web page cannot force an alarm through every operating-system power mode. Keep sound enabled or grant notifications when an alert is important.
- Changing the device clock while a timer is running changes an epoch-based target. Pause and resume to establish a new target.
- Picture-in-Picture and fullscreen depend on browser support and are shown only when the relevant API is available.
- This is product test evidence, not a laboratory calibration or a guarantee for safety-critical timing.