Why a Timestamp Is an Assertion, Not a Fact

A timestamp is a record of what one clock reported to one piece of software at one moment, stored in one encoding, and interpreted by your tool under an assumption. There are four independent places for it to be wrong — the clock, the encoding, the zone, and the semantics of the event — and an examiner who has not checked all four is reporting a number rather than a finding.

What layer did this timestamp come from?

Before the time itself, establish what kind of assertion it is. There are four layers, and they are made by different parties with different interests and different clocks.

Filesystem time is the operating system's record of when a container on a volume was touched. It tells you about the file, not the content, and it changes when things other than a human touch it.

Application time is a program's own record of its own event: a row in a browser history database, a message table, an entry in a document's internal properties. This is usually the layer that answers the question actually being asked, and it is written by software with its own idea of what the clock says.

Service or server time is a record made by something off the device — a mail server's Received headers, an identity provider's sign-in log, a cloud audit event. Each hop has its own clock, and on an email header you can see several of them disagreeing.

Embedded time is what a producing application wrote inside a file. A PDF's creation date, a camera's EXIF DateTimeOriginal, a document's internal created and modified properties. These travel with the file and survive copying, which makes them valuable and makes them a target.

A defensible chronology says which layer each entry came from. A chronology that silently mixes them will contain contradictions you cannot explain, because the contradiction is the mixing.

How is the time actually encoded?

Epoch and unit errors are common, mechanical, and produce results wrong by decades — so they are also the easiest class to catch.

Encoding	Epoch	Unit	Notes
Windows FILETIME	1601-01-01	100 ns	UTC. Used throughout NTFS and the registry.
Unix time	1970-01-01	s, ms or µs	UTC. Unit varies by application; SQLite stores whatever the app chose.
Apple Cocoa / Core Data	2001-01-01	s	UTC. Common across macOS and iOS application data.
Chrome / WebKit	1601-01-01	µs	UTC. Same epoch as FILETIME, different unit — a frequent confusion.
FAT	1980-01-01	see notes	Local time, no zone recorded.
HFS+	1904-01-01	s	Local time in HFS+.
APFS	1970-01-01	ns	UTC.

Resolution is not precision. NTFS stores 100-nanosecond units but Windows does not update file times at that granularity, so genuine values carry noisy low-order digits and a set of timestamps whose sub-second components are all exactly zero is a flag. FAT is coarser by design: two-second granularity on last-write, roughly ten milliseconds on creation, and a date only — no time at all — on last access. A FAT-formatted card with a last-access "time" of midnight is not evidence of midnight activity.

CyberChef will decode any of these interactively and is the fastest way to sanity-check a value your tool rendered oddly. When the data lives in a SQLite database, DB Browser for SQLite lets you look at the raw integer rather than a parser's interpretation of it — and for mobile artifacts specifically, the mobile forensics file format handbook documents what the stored values actually are.

Which zone, and how do you know?

Three separate questions hide inside "what time zone".

What did the filesystem store? NTFS stores UTC. FAT stores local time with no offset recorded, so a FAT timestamp is uninterpretable without knowing where the device was and what its clock was set to. exFAT carries timezone offset fields in its directory entries, but whether a given implementation populated them varies, so check rather than assume.

What was the system configured as? On Windows, the active zone is in the registry under HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation, where TimeZoneKeyName names the zone and Bias and ActiveTimeBias give the offset in minutes — the active bias being the one that accounts for daylight saving as of the last write. RegRipper will pull this, and it should be the first thing you extract from a Windows image, before any timeline, because every local-time rendering downstream depends on it.

What is your examination machine set to? This is the error that produces the most retracted exhibits. If your tool renders in the examiner's local zone and the report does not say so, you have published a chronology whose offset nobody can reconstruct. Render in UTC, label it UTC, and provide local-time conversions separately with the zone and the basis stated. Plaso normalises to UTC internally, which is one of the better reasons to use it as the timeline engine rather than assembling one by hand.

Daylight saving deserves a specific warning. In the repeated hour at a fall-back transition, a local-time-only timestamp is genuinely ambiguous — two real moments map to the same stored value, and no amount of analysis resolves it. Tools pick one silently. If a disputed event sits in that hour, say so.

How do you establish clock drift rather than assume it?

A system clock is a physical device that runs fast or slow, can be set by hand, and may or may not be synchronised. Domain-joined Windows machines usually synchronise up a hierarchy; standalone machines, embedded devices, cameras, DVRs, and phones that have never had network service routinely do not. A dead real-time-clock battery produces a machine that boots to its epoch — which is why images turn up with clusters of files dated 1980 or 1970.

The discipline is simple and it is not optional: measure the offset at collection. Record the subject system's displayed time against a reliable reference, with both values and the moment you compared them, in the collection notes. Collection guidance converges on this — ISO/IEC 27037 and SWGDE's digital evidence collection best practices both treat recording system time as part of the collection record, and NIST SP 800-86 frames the same expectation inside an incident response process. If you did not do it, the drift is unknowable after the fact except by inference from synchronised sources, and you must say that.

Where drift has been measured, apply it explicitly and show the arithmetic. Where it has not, present the device's own times as the device's own times and do not silently treat them as wall-clock truth.

The corollary matters more than the rule: never order events across two systems without establishing each system's offset to a common reference. A file written on a laptop at 14:02 by the laptop's clock and an email received at 14:01 by a mail server's clock do not establish that the email came first. That sequence is a conclusion, and its foundation is two clock comparisons you either made or did not.

Which divergences are meaningful and which are benign?

Most timestamp anomalies have innocent explanations, and the examiner's value is in knowing which.

Creation later than last modification. Almost always a copy. When Windows copies a file the destination is created at the time of the copy and commonly inherits the source's last-write time. This is the single most useful timestamp pattern in practice, and it is also why a creation time must never be described in a report as "when the document was written".

$STANDARD_INFORMATION diverging from $FILE_NAME on NTFS. A candidate indicator of timestamp manipulation, because tools that set times through the documented Windows interfaces affect the first and not the second. It is an indicator requiring corroboration, not a conclusion — archive extraction restores stored modification times, installers set times deliberately, sync clients write times from a server, and a restore from backup brings times from elsewhere entirely.

An access time with no plausible human act behind it. Where last-access updating is enabled at all, antivirus scanning, content indexing, backup software, and an examiner mounting the volume read-write all update it. An access timestamp is very weak evidence that a person read a file.

Times far in the future. A device whose clock was set forward, a timestamp arithmetic bug in an application, or a misidentified encoding. Check the encoding before concluding anything about the device.

Application time disagreeing with filesystem time. Usually correct and expected. A message database row records when the message was received; the database file's modification time records when the file was last written to disk, which may be much later and may reflect a completely unrelated write.

Documented manipulation does end up litigated. Cat3, LLC v. Black Lineage turned on a finding that the produced emails were altered versions and the authentic natives no longer existed, with the court applying Rule 37(e) and precluding reliance on the altered set. Rossbach v. Montefiore Medical Center is the harder version: the exhibit was internally inconsistent with the device that supposedly produced it. Both are cases where the technical analysis was about metadata that did not fit, and neither would have been reached by reading rendered timestamps off a report.

What can a timestamp never establish?

• That a person was present. A timestamp records a system event. Attribution to a human requires something else entirely, and usually requires several things.
• What the event was, as opposed to what the field is called. "Last accessed", "modified", "created" are labels on operating system behaviour, not descriptions of human action. The semantics differ between filesystems, between operating system versions, and between the API a program happened to call.
• Ordering across systems, without independent clock comparison. Stated above because it is the error that costs the most.
• That a value is original. Filesystem times are settable through documented interfaces by anything with write access. Embedded times are editable by anyone with the right library. Nothing about a timestamp resists alteration; what resists alteration is the existence of several independent records of the same event.
• Precision it does not have. A FAT write time is accurate to two seconds. A log that records to the second cannot adjudicate a half-second sequence. Reporting a derived interval to a precision finer than the source supports is an overstatement, and it is exactly the kind that gets found.

How do you build a chronology that holds?

Normalise everything to UTC and say so. Record, per source, which layer it is, which encoding it used, which zone applied, and what the measured clock offset was. Corroborate any load-bearing moment from at least two sources with independent clocks and independent custodians — an identity provider log, a DHCP lease, a filesystem artifact and an application database are four different clocks, and agreement between them is a real finding while disagreement is a finding of a different kind.

Timesketch exists for the collaborative version of this and is worth adopting before the timeline gets large enough to become one person's spreadsheet. Eric Zimmerman's tools cover the Windows artifact parsers with unusually careful documentation of what each timestamp in each artifact means, which is precisely the knowledge this article is about. 13Cubed works through artifact timestamp semantics in detail, and for the structures underneath, File System Forensic Analysis is where the definitions come from.

Then write the limits into the report rather than waiting to be asked. Casey's work on error and uncertainty and on expressing preliminary evaluative opinions, and the ENFSI guideline on evaluative reporting, all point the same way: the strength of a temporal inference is part of the finding, not a caveat appended to it.