F34.us
Menu

Architecture deep dive · 2 MIN READ

Why a Day Is the Unit of Truth

A deep dive into fingerprints, logical-day replacement, temporal history, and dataset-aware rollback.

Replace a day you can explain

An edited event may have no stable ID connecting it to its earlier version. Guessing which rows match can turn reconciliation into detective work. TimeTrackDB instead uses the logical day as the smallest complete unit it can replace with confidence.

Identify change at the day boundary

Every normalized event receives a deterministic fingerprint, and the sorted fingerprints for a day become a day digest. When another export arrives, unchanged digests can be ignored. A changed digest marks that day for reconciliation, allowing a large historical export to produce only a small, well-defined update.

Compare days, publish only changes

A changed digest leads to a whole-day replacement; the existing rows remain available in history.

flowchart TD
    Events[Normalized events] --> Digest[Sorted fingerprints and day digest]
    Digest --> Change{Digest changed?}
    Change -->|No| Skip[Leave day unchanged]
    Change -->|Yes| Publish[Replace day in a transaction]
    Publish --> History[Retain previous rows in history]

Publish and roll back whole days

Publication is transactional. The current rows for an affected day move into history, the replacement set becomes current, and the publication is recorded as one operation. Readers never see half of an update, while the historical table retains enough temporal information to reconstruct the state that existed at an earlier point.

This model also makes rollback understandable. A rollback targets an event dataset, a logical day or affected set of days, and a known historical state. It is a narrower and more auditable operation than restoring an entire database simply because one portion of an imported timeline was wrong.

PROJECT

More from TimeTrackDB

F34.us Background Image