The Clock in the Code: On the Unseen Calendars of Digital Preservation
We often imagine digital preservation as a battle against physical decay—the crumbling hard drive, the scratched disk. But a far more insidious threat lurks within the very logic of our systems, a silent countdown built into the code itself: the end of a file format’s epoch.
Most digital files don’t just store data; they also store time. A photograph is stamped with the moment it was taken, a document with its last save. This seems straightforward until you consider that our computers need a fixed point from which to count these seconds. This point is called an epoch. For many modern systems, that epoch is January 1, 1970, the start of the Unix timestamp. Time, for a computer, is often just a large integer counting the seconds from that moment.
But what happens when the number gets too big? This isn’t a distant, sci-fi concern. We’ve already faced Y2K38, the moment when 32-bit systems, which use a signed integer for time, will run out of positive numbers and roll over. It’s a digital calendar flipping back to 1901. While most modern systems have moved to 64-bit integers (buying us billions of years), the legacy data we work to preserve is often trapped in these older, more constrained temporal frameworks.
The Archaeology of Expiration Dates
This problem extends far beyond Unix time. Consider the humble JPEG. Its metadata can include a date, but what calendar does it assume? Or a proprietary database from the 1990s that uses a two-digit year field, forever locking a birthdate in a ambiguous century. The data is there, pristine and perfectly preserved, but its context—its place in time—is corrupted because the software that wrote it was built with a built-in expiration date.
Preserving these files isn't just about copying bits; it's about preserving their ability to be understood. This means also preserving the knowledge of their internal clocks. An archivist must become a horologist, understanding the specific temporal logic of a WordPerfect document, a Lotus 1-2-3 spreadsheet, or an early GIS dataset. They must know not just what the data is, but when it believes itself to be.
This challenge forces us to see digital preservation not as a single act of freezing something in time, but as a continuous process of translation. We must constantly migrate data from systems with failing clocks to systems with more robust ones, all while meticulously documenting the original timekeeping rules. It is a quiet, relentless effort to ensure that a future researcher can look at a preserved file and know not only what it contains, but the precise moment it was meant to represent. The data must remain, and its time must travel with it.
Notes & further reading
A few pages I came back to while writing this: