The Clock and the Calendar: Why Public Records Live in Two Kinds of Time

When you request a public record—a city council vote, a building permit, a court transcript—you’re usually asking for a snapshot. You want to know what was true on a specific date, the moment the gavel fell or the stamp was inked. The record, once created, belongs to the calendar. It is fixed in historical sequence. But the digital systems that store and serve that record live by the clock. They tick in a continuous, operational present. This quiet tension between calendar-time and clock-time is where so much of the fragility of our public memory hides.

Consider a municipal database. A clerk enters a decision. To the system, this is a transaction, a line added to a log file, a few bytes written to a disk. The system’s time is the timestamp on that transaction, pulled from an internal clock that might be seconds (or years) out of sync. Its concern is operational integrity: ensuring the write succeeded, the data is retrievable, the indexes are updated. This is clock-time—the time of processes, of uptime and downtime, of server logs that scroll into oblivion.

But the decision itself, the content of that record, exists in calendar-time. Its meaning is bound to the date it was made by a human, according to a legislative session or a fiscal year. Its legal force, its historical context, derives from its place in a human-made chronology of meetings, laws, and events. The system’s clock could drift, and the record would still be legally valid if its calendar-date is preserved and verifiable. Yet, we increasingly entrust the proof of that calendar-date to the very clock that is so prone to drift.

The Chasm Between Timestamp and Truth

This creates a silent chasm. A web archive captures a city’s budget page. The archive’s timestamp says 14:32:05 UTC on April 5th. But when was the budget actually passed? Was the page updated an hour after the vote, or a day? The archive’s clock-time documents the moment of capture, not the event the document describes. The ‘record’ is now a composite object: a human-calendar event nested inside a machine-clock event. If we lose the metadata that links one to the other—the meeting minutes that give context to the captured page—the record becomes unmoored. It exists in clock-time alone, a data point without a history.

Digital preservation often focuses on keeping the bits ticking—migrating files, emulating software, fighting bit rot. This is essential work on the clock-time axis. But equal effort must go into anchoring those bits to calendar-time. This means preserving not just the document, but the scaffolding of its creation: the ordinance number, the session date, the signing authority, even the finding aid or press release that announced it. It is the difference between preserving a single frame of a film and preserving the program listing that tells you when and where it was shown.

In paper archives, this binding was physical and implicit. A document in a box labeled "1992-1994 Council Votes" carried its temporal context in its very placement. Digital systems, optimized for the speed of the clock, scatter this context. A record becomes a row in a table, a file in a bucket, easily sorted by ‘last modified’ but severed from the calendar that gives it public meaning. Our challenge isn't just to make records readable for decades, but to ensure they remain intelligible as events in a civic timeline. We must build systems that don’t just tell time, but that also keep date.

Notes & further reading

A few pages I came back to while writing this: