CYBERDELIA SKUNKWORKSbureau / released information

PUBLIC RECORDS / METHOD GUIDE 003

TIMESTAMPS ARE EVIDENCE, NOT A TIMELINE.

A digital record may carry a document date, creation date, recordkeeping date, filesystem modification time, scan time, export time, release date, web publication time, and Cyberdelia retrieval time. They can all be legitimate and still describe different events.

CORE IDEAChronology is reconstructed by identifying what each timestamp means, who or what generated it, which clock it used, and whether later handling could have changed it.

DATE TYPES

Start by naming the event the date claims to represent.

The date printed inside a memo may represent when it was authored or signed. An archival description may give the period when the records themselves were created. A recordkeeping system can capture when the item was received, filed, or declared a record. A digitization workflow can produce a separate date-and-time for when a paper source became a digital image.

NARA explicitly distinguishes among these concepts. Its archival guidance separates the dates when records themselves were created from recordkeeping dates and from the time period covered by the subject matter. Metadata guidance for digitized records also distinguishes the source record's creation date from the date and time the digital image was created.

Those distinctions are not bureaucratic trivia. They prevent a 2025 scan of a 1963 memo from quietly becoming a “2025 document.”

FILESYSTEM TIME

Modified time often tells you about the file, not the historical event.

Filesystems commonly store timestamps such as modification, creation, access, or metadata-change time. Their exact meaning depends on the filesystem, operating system, copy tool, archive format, and workflow.

A file copied to a new volume may gain a new creation time while preserving or changing modification time. Extracting a ZIP can assign timestamps derived from the archive entry. Cloud synchronization can rewrite metadata. Conversion software can produce a fresh output whose modified time reflects conversion, not original authorship.

NARA's accessioning support tools treat date modified as one metadata element alongside path, file size, extension, and SHA-256. That is the correct epistemic posture: useful evidence, not self-authenticating chronology.

DIGITIZATION

The scan has a birthday separate from the paper.

When physical records are digitized, the digital object is a derivative with its own creation event. NARA metadata guidance now requires distinct fields that can represent the date the source record became a Federal record and the date/time the digital image itself was created.

That distinction matters when evaluating image quality, OCR, redaction workflow, or chain of custody. A scan made decades later can still faithfully represent the paper record, but its technical metadata describes the digitization process rather than the historical origin of the content.

EMAIL + SYSTEM LOGS

Application timestamps inherit application assumptions.

Email can contain Date headers supplied by clients, server-received times, transport timestamps, mailbox metadata, and export-container metadata. Logs can contain local time, UTC, monotonic counters, device uptime, GPS time, or vendor-specific epochs. Cameras and embedded devices may use clocks that were never synchronized correctly.

The first question is therefore not “what time does it say?” but “which clock generated this field?” The second is whether that clock had a trustworthy relationship to civil time at the relevant moment.

TIME ZONES

Local time without zone context is an incomplete coordinate.

Two events recorded as 14:05 may be hours apart if the systems were in different zones. Daylight-saving transitions can make local times repeat or skip. Historical timezone rules can differ from modern rules. Devices may label UTC as local time or vice versa.

Preserve the original representation. When normalizing for analysis, record the transformation and the assumed zone. Do not silently convert ambiguous local time into UTC and then forget that an assumption entered the timeline.

CLOCK ERROR

A precise timestamp can be precisely wrong.

Digital timestamps often display to the second, millisecond, or finer. That formatting precision does not establish clock accuracy.

Embedded devices drift. Workstations can have bad timezone configuration. NTP may be unavailable. Cameras can sit on factory-default dates. Manual clocks can be wrong by minutes or hours. A system reboot can reset time before synchronization occurs.

Where timing matters, seek independent anchors: network time logs, GPS, server receipt, telephone records, broadcast events, known transactions, or another system whose clock quality is better characterized.

RELEASE TIME

Publication is another event, not the origin of the record.

An agency can create a record, maintain it for years, review it for release, redact it, export it, and publish it online much later. A web page's publication or modification time describes that release surface.

Cyberdelia therefore records retrieval time separately from the source record's historical dates. Our archive timestamp answers “when did we acquire these bytes?” It does not claim “when was this evidence created?”

CONFLICT

Contradictory clocks are a research result.

If an internal document date, filename date, filesystem timestamp, archive description, and agency release page disagree, do not immediately choose the one that fits the preferred story. Record the conflict.

Then ask what transformations could explain it. Scanning, migration, copying, restoration from backup, archival export, redaction processing, timezone conversion, or simple clock error may produce different timestamps without implying deception. Conversely, an unexplained timestamp inconsistency can be legitimately important. The key is not to skip directly from discrepancy to motive.

TIMELINE METHOD

Build chronology from typed events.

A useful evidence timeline stores more than a date:

event type — authored, received, recorded, scanned, modified, exported, released, retrieved.

timestamp value — preserved exactly as observed.

timezone/clock basis — UTC, local with zone, unknown, device uptime, or other.

source — document text, metadata field, server log, archive description, agency release page.

confidence — how strongly the timestamp is tied to the claimed event.

transformation — any normalization or conversion used for comparison.

conflict notes — competing timestamps and plausible explanations.

Once typed this way, a timeline can express uncertainty instead of laundering it into a single sorted column.

HASHES + TIME

A hash can stabilize the object while the timestamp interpretation remains uncertain.

SHA-256 lets us later confirm that the preserved bytes match the bytes acquired at a recorded retrieval time. That is strong evidence about object identity across custody.

It does not make the timestamps inside the object true. A forged document hashes perfectly. A camera with a bad clock produces files that hash perfectly. Integrity and chronology are complementary evidence layers, not substitutes.

BOTTOM LINE

Dates need provenance just like documents do.

Every timestamp is produced by some mechanism. Identify the mechanism, the event, the clock, and the transformations before letting the value order history.

A timestamp is a claim about time made by a system. Treat the system as part of the evidence.