ENGINEERING NOTE 12 / 50 · SMS
Make an SMS expiry countdown survive clock drift
The browser countdown is presentation. The server owns expiry and must reject operations based on its own clock and order state.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Return absolute expiry
Return server_now and expires_at together. Estimate a display offset instead of trusting the device wall clock. A customer whose laptop is ten minutes fast should not see a new order expire immediately. Refresh the estimate after long suspension.
Do not use timer ticks as truth
Browsers throttle timers in background tabs. Subtracting one second per callback will drift. Recompute remaining time from timestamps on each render. When the display reaches zero, query final status; a message may already have arrived while the tab was suspended.
Keep actions server-checked
A client can submit a cancellation after its display deadline. The server should use authoritative state and applicable terms rather than accepting a client-supplied remaining_seconds value. A display bug should not change refund eligibility or extend a paid allocation.
Illustrative implementation
offset = server_now_ms - device_now_ms
remaining = max(0, expires_at_ms - (device_now_ms + offset))
# Server rechecks expiry independently.Acceptance check
Test clocks ten minutes ahead and behind, then suspend the tab. Confirm the final state still comes from the server.