The example payload in the post carries its own proof, if you do the arithmetic on it. Between the `last_sync_utc` of 2026-08-24T22:00:03Z and the `rtc_utc` of 2026-08-25T04:31:07Z there are 23,464 seconds [3], and across that window the device reports `drift_correction_ms` of 1650 [11]. That works out to 70 parts per million, or 6.1 seconds a day [4]. The same record reports `temperature_c` of -18.4 [11]. Feed -18.4 into the curve the post quotes, k(T - T0) squared with k at 0.035 ppm per degree squared, and you get 66 ppm [5]. The one field in the payload that admits the clock was wrong agrees with the physics that made it wrong.
Nothing in that sequence is a failure. No packet was lost, no part was out of spec, and each file is an accurate record of what its own oscillator counted [8]. That is the reason the defect clears code review, staging and the first pilot [8]: you find it by asking a question, never by watching a dashboard.
Treat 6.1 seconds a day as a claim about someone else's lane. It assumes the device sits at -20 C for the full 24 hours [4]. Drift only accrues while cold, so a route spending twelve hours at ambient and twelve in the freezer lands nearer 3 seconds a day [8]. The k in that formula is also a datasheet range rather than a measured constant, and at the ends of 0.020 to 0.045 the same calculation gives 3.5 to 7.9 seconds a day [5]. On top of that sits an independent factory tolerance of plus or minus 20 ppm per unit, which is 1.73 seconds a day of unknown sign [7]. The post's honest summary is a bound, not a figure: near-zero to about 10 seconds a day between two specific units, typically around 6, unmeasured for your pair [6].
Six seconds a day over an eleven-day lane is about 67 seconds [1]. The claim the light channel exists to support is that the temperature rose 90 seconds after the door opened [7]. Uncertainty of 67 seconds is roughly three quarters of the interval being asserted [2], which is why the post says such a record is worth what a plain temperature log is worth [7].
Compensation works, arithmetically. A TCXO RTC gets to a couple of ppm [9], which is 0.17 seconds a day, or 1.9 seconds over the same eleven days [6] and comfortably inside a 90-second claim. The problem the author flags is verification: plenty of ordinary RTCs expose an offset register, and almost none publish the residual [9]. An integrator reading a payload cannot tell a compensated clock from an uncompensated one.
The structural answer is to sample every channel you intend to correlate on one MCU against one oscillator and emit them as a single record [10]. Inside that record, ordering is on the pair (boot_id, uptime_ms), because uptime_ms is monotonic within a power cycle but resets to zero on every boot, and a mid-trip brownout from a TX burst sagging the rail is a known event on primary-cell hardware [12]. Sort on uptime_ms alone and a post-reboot reading files itself back at the start of the trip [12]. `rtc_utc` stays a label for placing the trip on a wall clock, since platforms that sort by it see events appear to travel backwards [13]. This is one post, and its example schema is written around one device model [11], so read it as an integration note rather than a standard. The arithmetic in it holds either way.
