https://mikemwita.com/buglog/Recent content in Bug Log on Mike MwitaHugoen-ushttps://mikemwita.com/buglog/the-clock-that-kept-slipping/Sun, 02 Aug 2026 09:00:00 +0300https://mikemwita.com/buglog/the-clock-that-kept-slipping/<p><span class="dropcap">I</span> was integrating an external API. The datetime it stamped on every response never agreed with my local clock — and not by a clean, constant amount. Sometimes it was 4 minutes behind. Later, 8. Then more. The gap kept drifting.</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl"> our clock their timestamp gap </span></span><span class="line"><span class="cl"> ───────────────────────────────────────────── </span></span><span class="line"><span class="cl"> 10:14 10:10 −4 min </span></span><span class="line"><span class="cl"> 11:02 10:54 −8 min </span></span><span class="line"><span class="cl"> 13:40 13:29 −11 min </span></span><span class="line"><span class="cl"> ↑ </span></span><span class="line"><span class="cl"> not a constant — it grows </span></span></code></pre></div><h2 id="the-wrong-theory"> The Wrong Theory <a href="#the-wrong-theory" class="heading-anchor">#</a> </h2> <p>My first instinct was that we were sending the wrong value, so I checked the payload. The date was correct. That check cost me time: a timezone shift usually leaves the date component intact and only moves the clock, so a date-only comparison passes while the instant is wrong. The date only flips when the shift crosses midnight — which is why &ldquo;the date is right&rdquo; <em>feels</em> like evidence and isn&rsquo;t.</p>