A WordPress‑based implementation of the Kagodora clock was found to lose time – over 5 hours in a single month – while its Node.js counterpart remained perfectly accurate. Both versions started from the same initial state, yet the WordPress clock consistently fell behind.

Root Cause

The clock uses a custom time system (rays, rings, turns, etc.) with non‑60‑second units. On page load, the client fetches the current Kagodora state from the server and stores it, then calculates elapsed time using the browser’s Date.now().

The drift stems from client‑side inaccuracies:

• A static base timestamp (state.timestamp) is set once and never updated.
• Over extended periods, browser throttling (especially in background tabs) and micro‑delays in requestAnimationFrame accumulate.
• These small errors compound, causing the elapsed‑time calculation to shift gradually, making the clock run slower than real time.

Solution

A periodic re‑sync mechanism was implemented to correct the drift without altering the core counting logic:

• The Kagodora time calculations (multiples of 90, 8100, etc.) remain unchanged.
• Every 30 seconds, the client fetches the server’s current Gregorian timestamp via an existing AJAX endpoint.
• Only the base timestamp (state.timestamp) is updated – the Kagodora state values (ray, ahdo, etc.) stay untouched.
• This resets the reference point, eliminating any accumulated drift.

The clock continues to count independently in Kagodora units, while the re‑sync acts as a periodic “reality check” against the server’s time.

Result

The clock now maintains accurate time, with no measurable lag over time. The server does not drive the counter; it merely provides occasional anchors. All custom Kagodora math remains intact.