Metadata Is Not Truth: Why Digital Timestamps Can Mislead Forensic Investigations
A Critical Review of Timestamp Semantics, Temporal Artefacts, Clock Integrity, File-System Behaviour and the Forensic Interpretation of Digital Time
Executive Summary / Abstract
Digital timestamps are among the most frequently relied-upon artefacts in digital forensic casework, yet the literature on file-system behaviour, clock integrity and timestamp semantics shows that their evidential meaning is far less settled than their numerical precision suggests. This review synthesises peer-reviewed digital forensics research, primary technical specifications, and authoritative guidance to examine the distance between a recorded timestamp value and the human event it is used to prove. Drawing on experimental studies of NTFS $STANDARD_INFORMATION and $FILE_NAME behaviour (Galhuber & Luh, 2021), cross-platform exFAT inconsistencies (Nordvik & Axelsson, 2022), POSIX non-compliance on Unix-like systems (Thierry & Müller, 2022), cloud synchronisation artefacts (Quick & Choo, 2013, 2014), Android timestamp ambiguity (Kaart & Laraghy, 2014), and browser timing delay (Groß, Dirauf, & Freiling, 2020), the article develops two original interpretive frameworks — the Temporal Evidence Ladder and the Temporal Uncertainty Propagation Model — intended to help practitioners and researchers reason more explicitly about inferential distance. The review does not argue that timestamps are untrustworthy; it argues that their evidential weight is conditional on understanding how, by which system, under which clock, and through which transformations a given value came to exist.
Key Findings at a Glance
- Numerical precision (seconds, milliseconds, nanoseconds) is a property of storage resolution, not a guarantee of evidential accuracy about a real-world event.
- The same human-readable label — "Created," "Modified," "Accessed" — can denote different underlying events depending on filesystem, operating system, API and application (Galhuber & Luh, 2021; Kaart & Laraghy, 2014).
- Cross-platform experiments show that even a single, well-specified filesystem (exFAT) is implemented inconsistently across Windows, macOS and Linux, and that forensic tools do not always parse the resulting values correctly (Nordvik & Axelsson, 2022).
- POSIX itself does not fully determine Unix-family timestamp behaviour; Linux, FreeBSD, OpenBSD and macOS diverge from the specification and from one another (Thierry & Müller, 2022).
- Cloud synchronisation and file transfer operations systematically alter, regenerate, or overwrite timestamps in ways that depend on the transfer method, not the file's history (Quick & Choo, 2013, 2014; Chung, Park, Lee, & Kang, 2012).
- Browser history and cache timestamps do not reliably mark the instant of user action — controlled experiments found routine multi-second delays and occasional URL mismatches (Groß, Dirauf, & Freiling, 2020).
- Clock correctness cannot be assumed; it must be argued using corroborating "time anchors" and tested against causal relationships between events (Willassen, 2008a, 2008b; Vanini, Hargreaves, van Beek, & Breitinger, 2024).
- Distributed and cloud environments introduce genuine ordering ambiguity that a single wall-clock timestamp cannot resolve without causal or logical corroboration (Lamport, 1978).
1. Introduction: The Illusion of Temporal Precision
Digital timestamps carry an unusual rhetorical power in forensic reporting. They provide dates, hours, minutes, seconds, and increasingly sub-second resolution, and this granularity often reads as certainty. Yet numerical precision does not necessarily equal evidential accuracy. A value can be recorded with nanosecond resolution and still misrepresent the moment a human being acted, because the resolution describes how finely a clock subdivides time, not how reliably that clock was set, how faithfully the recording layer preserved the value, or how correctly a parser later interpreted it.
It is useful to keep several distinct properties separate from the outset, because forensic writing tends to collapse them into a single impression of "reliability":
- Precision — the resolution at which a value is expressed (seconds vs. nanoseconds).
- Accuracy — how closely a recorded value corresponds to the true physical time of the event it purports to describe.
- Validity — whether the value actually measures the thing the examiner believes it measures (a "creation" timestamp that in fact marks a copy operation is precise and possibly accurate, but not valid as evidence of original authorship).
- Reliability — whether the same measurement process would produce a consistent result under repetition, across tools, and across re-analysis.
- Temporal resolution — the granularity of the underlying clock and storage format, which sets an upper bound on precision but says nothing about accuracy.
A timestamp can be maximally precise, internally consistent, and still forensically misleading, because none of those properties speak to the semantic question of what event actually produced the value. That semantic question is the subject of this review.
2. A Timestamp Is a Representation, Not an Event
The central conceptual move this article asks readers to make is to stop treating a timestamp as a synonym for the event it appears to name, and instead treat it as the terminal output of a chain of technical representations. A useful way to see this is to separate the layers that sit between a human action and the number an examiner eventually reads in a forensic tool.
Temporal Event Layers
Consider the following chain, which rarely collapses into a single instant:
Human action → Application processing → Operating-system operation → Filesystem update → Metadata storage → Synchronisation/transformation → Forensic acquisition → Tool interpretation → Human inference.
Each arrow in that chain is a place where temporal meaning can drift. A user's click in a browser is processed by the rendering engine, which requests a resource, which is written to an on-disk cache by the operating system's I/O layer, which updates filesystem metadata according to rules that vary by mount options and driver implementation, which may later be synchronised to a cloud backend or copied to another device, which is eventually imaged by an examiner, parsed by a forensic tool that applies its own assumptions about time zone and encoding, and finally interpreted by a human analyst who converts a number into a sentence about what "the user did." Groß, Dirauf, and Freiling (2020) demonstrated this empirically for browsers: in large-scale controlled experiments, the timestamp written into browser history and cache entries for Chrome and Firefox routinely lagged the actual user action by several seconds, and in a small number of cases the recorded domain did not match the domain the user actually visited. The lag is not a defect to be patched; it is a structural property of how the layers in the chain are engineered.
Because each layer can be implemented differently by different vendors, versions, and configurations, the "same" nominal event — a file being created, a page being visited, a message being sent — can leave systematically different temporal fingerprints depending on which software wrote them.
3. Timestamp Semantics: What Does the Field Actually Mean?
The MACB acronym — Modified, Accessed, Changed/Created, Birth — is often taught as though it names four universal categories. In practice, the semantic content behind each letter is filesystem-specific, and even within a single filesystem it can be attribute-specific.
NTFS is the clearest illustration. Every file record in the Master File Table can carry two independent sets of MACB timestamps: one in the $STANDARD_INFORMATION ($SI) attribute, and one in the $FILE_NAME ($FN) attribute (Galhuber & Luh, 2021). $SI timestamps are the ones exposed by Windows Explorer, PowerShell and most forensic tools by default, and — critically — they can be modified by ordinary user-mode API calls, which is precisely why "timestomping" anti-forensic tools target them. $FN timestamps, by contrast, are written by the NTFS kernel driver and are not exposed through the standard file-property dialogs, which makes them both less familiar to examiners and considerably harder for an unsophisticated actor to falsify consistently. Galhuber and Luh's (2021) controlled experiments across Windows versions found that common file operations produce identifiable, reproducible timestamp patterns, and that of several third-party timestamp forgery tools tested, only one was capable of altering the full range of timestamps across both attributes — meaning that a mismatch between $SI and $FN values, or between either attribute and independent $LogFile transaction records, can itself become evidence of manipulation rather than merely a data point to explain away.
Outside NTFS, semantics diverge further. Ext4 and other Unix-family filesystems follow the POSIX st_atime/st_mtime/st_ctime model plus an optional birth time, but Thierry and Müller (2022) showed through 187 automated compliance tests spanning Linux, FreeBSD, OpenBSD and macOS that no tested operating system was fully POSIX-compliant, and that middleware libraries such as GIO (used by GNOME's file manager) update timestamps differently from command-line utilities performing what a user would consider "the same" copy operation. exFAT compounds the problem further: Nordvik and Axelsson (2022) found that Windows, macOS and Linux drivers for the same exFAT specification handle the directory-entry UTC-offset field inconsistently, and that four widely used forensic tools — Autopsy, X-Ways Forensics, EnCase, and FTK Imager — did not uniformly interpret the resulting values, meaning the same physical bytes on a USB drive could be displayed as different times by different software.
The forensic interpretive consequence is not that any one of these systems is "wrong." It is that the human-readable label on a timestamp field is a convenience gloss, not a specification, and the specification that actually governs the value's meaning must be checked against the filesystem, the operating system version, the driver implementation, and — separately — the forensic tool's parser.
4. File-System Behaviour and Temporal Artefacts
The question posed in this section — does a timestamp describe the history of the content, the file object, the filesystem entry, or a specific operation? — has no single answer, because file operations interact with metadata in operation-specific and filesystem-specific ways.
Copying a file within the same NTFS volume typically produces a new $FN creation time equal to the moment of the copy, while the $SI creation time behaviour depends on the copying utility and API used (Galhuber & Luh, 2021). Moving a file within the same volume, by contrast, is often a metadata-only operation that can leave the original creation timestamp untouched, because no new file record needs to be written — the same nominal "create" label therefore means something different depending on whether the file crossed a volume boundary. On Unix-family systems, Thierry and Müller (2022) documented that GIO's file-copy implementation inherits the modification time from the source file while updating access, change and birth times — a deviation from the plain cp utility's behaviour (which updates the full MACB set), meaning that the choice of copying application, not merely the operating system, leaves a distinguishable temporal fingerprint.
Archive extraction and backup restoration introduce another layer of ambiguity: many archive formats and backup tools attempt to preserve original modification times (to support tools such as make that depend on relative freshness), while creation and access times are frequently regenerated at the moment of extraction. An investigator who reads "Created: [date of alleged offence]" on a restored file without asking whether that value survived a backup-and-restore cycle risks anchoring an entire narrative to an artefact of the restoration process rather than the original event.
The recurring theme, consistent with Galhuber and Luh's (2021) broader argument, is that the number and diversity of possible file operations — and the corresponding number of distinct timestamp patterns they produce — is large enough that no fixed lookup table can substitute for testing the specific software, version and operation actually implicated in a case.
5. Clock Integrity: The Device Clock Is Itself Evidence
Every timestamp inherits the correctness — or incorrectness — of the clock that produced it. Willassen (2008a) formalised this problem by defining a "clock function" that maps physical time onto the values a system clock actually reports, explicitly allowing for the possibility that the function is non-monotonic (a clock can appear to run backward if it has been manually adjusted) or coarse enough that distinct real-world events map onto identical stored values. Willassen's contribution was to propose testable "clock hypotheses" — falsifiable claims about how a clock's reported time diverged from real time across a given period — that can be evaluated against the causal ("happened-before") relationships between recorded events, drawing on the same happened-before formalism Lamport (1978) introduced for distributed systems more broadly (Willassen, 2008a, 2008b).
This is not a purely theoretical concern. Buchholz and Tjaden's large-scale survey of internet-connected hosts, cited in subsequent event-reconstruction literature, found that a substantial proportion of observed clocks were inaccurate by more than ten seconds and did not conform to simple linear-drift models — meaning investigators cannot safely assume that an uncorrected clock's error is small, or that it grows in a predictable direction (as summarised in the timeline-reconstruction literature synthesised by Vanini, Hargreaves, van Beek, & Breitinger, 2024). Vanini et al. (2024) built directly on Willassen's approach, introducing the operational concepts of "time anchors" — artefacts that carry both an internal, device-generated timestamp and an independently verifiable external time reference — and "time anomalies," which are the discrepancies between the two that reveal clock skew. Their DFRWS 2024 study used a real homicide case (the 2015 Fitbit/smart-home case involving Richard and Connie Dabate) to illustrate how naturally occurring anchors — network requests, externally timestamped log entries, and similar artefacts — can be used to test whether a system's clock was behaving correctly during the period under investigation, rather than assuming it.
The practical corollary is that clock correctness cannot be assumed as a background condition of the investigation; it is itself a proposition that needs evidence. Virtual machines, suspended and resumed systems, dual-boot configurations sharing a single hardware clock across operating systems that interpret it differently (as local time versus UTC), and simple manual misconfiguration are all well-documented mechanisms by which a system's reported time diverges from real time, independently of any hostile tampering.
6. Time Zones, UTC and the Forensic Conversion Problem
A second, largely independent source of error sits at the interpretation layer rather than the storage layer. NTFS $SI and $FN timestamps are stored in UTC and are, in that specific sense, immune to time-zone ambiguity at the point of storage (Galhuber & Luh, 2021) — but the value an examiner ultimately reads has usually been converted to a local, human-readable representation by a forensic tool, and that conversion step is where errors are introduced. exFAT stores timestamps in local time accompanied by a UTC-offset field that is, in principle, supposed to make correct UTC conversion possible — yet Nordvik and Axelsson (2022) found that different operating-system drivers populate and honour that offset field inconsistently, and that not all of the forensic tools they tested applied the offset the way the specification intends, producing displayed times that could be off by a fixed number of hours depending on which tool parsed the same directory entry.
Kaart and Laraghy (2014) documented an Android case study in which the device's configured time zone did not match its physical location, while the underlying clock had nonetheless been set correctly for the location where the device actually was — a configuration that, at first glance, appeared to create a compounding daylight-saving-time problem, since the two candidate time zones enforced DST transitions on different calendar dates. Their case study is a useful corrective to the assumption that time-zone handling is a simple, mechanical offset: a device can present internally consistent but externally misleading local-time values, and the correct reconstruction requires establishing the physical time zone independently of what the device claims to be configured for.
The general principle worth foregrounding here is that temporal evidence can be altered at the interpretation layer without the underlying data being altered at all. A $SI timestamp stored correctly in UTC on disk can be displayed incorrectly by a tool that applies the host examination machine's time zone instead of the correct one, or that fails to account for a historical daylight-saving rule change in the relevant jurisdiction. The raw bytes on the disk image are unimpeachable; the number in the report can still be wrong.
7. The Problem of Timestamp Transformation
Timestamps are not always preserved verbatim as data moves between systems — they can be preserved, regenerated, normalised, rounded, truncated, or inherited, and which of these happens depends on the specific pathway involved. Nordvik and Axelsson (2022) noted that exFAT's ten-millisecond creation-time field is frequently truncated or rounded differently by different implementations. Thierry and Müller (2022) observed that GIO's file-copy operation on Linux truncates modification and access timestamps to microsecond resolution even when the underlying filesystem supports finer granularity — a detectable fingerprint distinguishing files copied through a GNOME file manager from files copied with the standard cp utility.
Greater stored resolution — nanoseconds instead of seconds — does not by itself tell an investigator anything more about when a human being acted, because resolution is a property of the storage format, not of the underlying knowledge about the event. A nanosecond-resolution timestamp generated by a clock that has never been synchronised to a reliable external reference conveys a false sense of precision: the number can be reported to nine decimal places while being wrong at the level of minutes.
8. Copying, Moving and Synchronisation: When "Created" Does Not Mean Created
Cloud synchronisation is the clearest domain in which the word "created" detaches from its everyday meaning. In a series of controlled experiments, Quick and Choo (2013a, 2013b, 2014) examined Dropbox, Microsoft SkyDrive (now OneDrive) and Google Drive and found that downloading the same cloud-stored file through a web browser versus through the dedicated client application produced systematically different local timestamps: browser downloads tended to reset creation and modification times to the moment of download, whereas client-software synchronisation more often preserved the "last written" time associated with the file in the cloud (Quick & Choo, 2013a). Their companion study specifically testing whether the act of forensic collection itself altered cloud data found that upload, storage and download did not change file contents, but did produce timestamp differences depending on the collection method used (Quick & Choo, 2013b) — meaning an investigator's own acquisition choices can shape the very artefact being relied upon as evidence. Chung, Park, Lee, and Kang (2012) reached parallel conclusions studying cloud storage investigation more broadly, emphasising that client software, browser cache, and server-side records each preserve a different, partial view of a file's synchronisation history.
The central forensic question — what event does a timestamp describe after a file has travelled through multiple systems? — therefore has no universal answer. It depends on the filesystem of origin, the destination filesystem, the specific application or protocol used for the transfer, and the storage medium. What the literature does establish is a testable methodology: reproduce the alleged transfer pathway experimentally, using the same software versions where feasible, and compare the resulting timestamp pattern to the one observed in the evidence, rather than reasoning from a filesystem specification in the abstract.
9. Application-Generated Timestamps
Many of the timestamps examiners encounter are not written by the operating system or filesystem at all, but by an application that maintains its own notion of time, independent of (and sometimes inconsistent with) the underlying device clock. Mobile applications built on SQLite routinely store their own timestamp columns using Unix epoch time, and the semantics of those columns are defined by the application's database schema, not by any filesystem convention (Kaart & Laraghy, 2014). When a forensic examiner observes such a value, the clock being observed may be the device's local clock at the moment a record was written, a server-supplied timestamp received over the network and merely stored locally, or a value inherited from a prior synchronisation and never updated. Distinguishing between these requires understanding the specific application's synchronisation architecture rather than assuming a uniform convention.
10. Cloud Forensics and Distributed Time
Distributed systems raise an ordering problem that is qualitatively different from single-device clock drift. Lamport's (1978) foundational analysis of distributed computing established that, in a system where messages take non-negligible time to travel between nodes, there is no way to recover a single, universally agreed physical ordering of events from local clocks alone; at best, a "happened-before" partial ordering can be recovered from causal relationships (a message cannot be received before it is sent), and Lamport showed how logical clocks can be used to construct a consistent, if not necessarily "true," total ordering. This is directly relevant to cloud forensics: when a file exists in a client cache, a synchronisation queue, and a server-side object store simultaneously, each location may record a different local timestamp for what a human would describe as "the same" save event, and eventual-consistency architectures mean that server-side records themselves may not converge on a single value instantaneously (Chung, Park, Lee, & Kang, 2012; Quick & Choo, 2014). A single timestamp, taken from a single location in a distributed system, cannot by itself establish a global ordering of events; establishing that ordering requires either a trusted, centrally synchronised reference (an NTP-disciplined server clock, per Mills, 1991, 2003) or explicit causal corroboration between the artefacts recovered from each location.
11. Mobile Forensics and Temporal Ambiguity
Mobile devices compress many of the ambiguities discussed so far into a single, densely populated set of SQLite databases. Kaart and Laraghy (2014) demonstrated that Android devices frequently mix "naive" timestamps (no time-zone information attached) with UTC timestamps within the same investigation, requiring explicit normalisation before any two records can be safely compared, and that clock skew between the examined device and any external reference must be independently established rather than assumed to be zero. NIST's mobile device forensics guidelines likewise emphasise that examiners must document and account for the specific extraction method and its effect on recoverable metadata (Ayers, Brothers, & Jansen, 2014). Because mobile applications update frequently and often change their underlying database schema between versions, a timestamp interpretation that was valid for one version of an application's local database may not hold for the next (Kaart & Laraghy, 2014) — a caution equally applicable to app-specific SQLite forensics on messaging platforms.
12. Browser and Internet Artefacts: When Did the User Actually Act?
The distinction between "an artefact exists at time X" and "the user deliberately performed an action at time X" is nowhere more empirically documented than in browser forensics. Groß, Dirauf, and Freiling (2020) ran a large-scale, automated experiment comparing the true (ground-truth, scripted) time of a browsing action against the timestamp subsequently recorded in Chrome's and Firefox's history and cache databases. They found that history entries for a page "open" action were, in ninety percent of cases, recorded within five seconds of the true action for the browsers tested — but that meaningful delay was routine rather than exceptional, that "click" and "open" actions produced measurably different delay distributions, and that in a small number of cases the recorded URL did not match the URL the automated script had actually visited. Their explicit forensic recommendation was that examiners should treat a browser-history timestamp as evidence that an action occurred at approximately that time, with a quantifiable margin, rather than as proof that it occurred at that literal instant — the danger being precisely the conversion of "an artefact exists at time X" into "the user deliberately performed action Y at time X," which the data does not, on its own, support.
13. Multimedia Metadata: When Was the Photograph Actually Taken?
EXIF metadata embeds a capture timestamp directly in an image file, distinct from the filesystem-level creation and modification timestamps of the file containing it (see the JEITA-standardised EXIF format, discussed in the tool-reliability literature; e.g., the metadata-extraction evaluation summarised in recent forensic tool-benchmarking work). Recent tool-validation research comparing forensic metadata-extraction utilities found substantial variance in accuracy and completeness across tools and across image-transfer pathways, with some fields — including capture time — surviving direct transfers (USB, email) far more reliably than transfers through messaging and social-media platforms, which frequently strip or overwrite EXIF data during compression and re-encoding. The forensic question is therefore not simply "what does the EXIF timestamp say," but which of several available timestamps — capture time embedded in EXIF, filesystem creation time, filesystem modification time, and any cloud-backup or upload timestamp recorded separately — corresponds to the moment of image capture rather than to a later processing, editing, export, or re-upload event. These are frequently different values, and a platform's re-encoding pipeline can silently discard the very field an investigator most needs.
14. Logs Are Not Neutral Witnesses
Log timestamps are subject to their own chain of representation: an event is generated, a logging subsystem records it (sometimes after buffering), the record may be rotated, transmitted to a remote collector, and finally ingested and indexed by an analysis platform — and each of these stages can introduce its own delay or reordering. NIST's guide to integrating forensic techniques into incident response explicitly frames logs as one category among several data sources requiring careful examination of collection and generation timing, rather than as an intrinsically authoritative record (Kent, Chevalier, Grance, & Dang, 2006). A log timestamp may represent the time an event was observed by the generating process, the time it was written to local storage, the time it was transmitted, the time it was received by a collector, or the time it was indexed for search — and in distributed logging architectures spanning multiple hosts, these are not guaranteed to agree even approximately unless the hosts share a disciplined, NTP-synchronised time source (Mills, 1991, 2003).
15. Timestamp Correlation and Digital Timeline Reconstruction
Formal event-reconstruction methods attempt to move beyond reading individual timestamps toward testing whether a proposed sequence of events is consistent with the full set of recovered artefacts. Gladyshev and Patel's (2004) finite-state-machine approach to digital event reconstruction, and their subsequent work formalising "event time bounding" (Gladyshev & Patel, 2005), provided an early rigorous vocabulary for this: rather than asserting that an event happened at a specific instant, an examiner can establish a bounded interval within which an event must have occurred, given the constraints imposed by the surrounding evidence. Hargreaves and Patterson's (2012) automated timeline-reconstruction work, and the more recent survey-level treatment of timeline-based event reconstruction as a distinct sub-field, both stress that correlation between independent timestamp sources increases confidence but does not, by itself, establish causation — two artefacts can be temporally consistent with a hypothesis while remaining equally consistent with one or more competing explanations that the investigator has not yet considered or excluded.
16. The Problem of "False Chronology"
This review proposes the term false chronology to describe a forensic reconstruction in which the sequence or timing of events appears internally coherent but rests on timestamps whose semantics have been misunderstood, or on values that have inherited an error from an earlier stage in the representational chain described in Section 2. The causes documented throughout the literature reviewed above are cumulative rather than exotic: a time-zone conversion applied by the wrong tool (Nordvik & Axelsson, 2022), an uncorrected clock drift never tested against an independent anchor (Willassen, 2008a; Vanini et al., 2024), a copy operation that reset a creation time during cloud synchronisation (Quick & Choo, 2013a), a browser recording an action several seconds later than it occurred (Groß et al., 2020), or a mismatch between $SI and $FN attributes left unexamined (Galhuber & Luh, 2021). None of these causes require malicious intent; each is a routine, well-documented feature of ordinary system behaviour. False chronology is therefore best understood as an inferential risk inherent to timeline construction, to be actively tested for, rather than a sensational failure mode to be invoked only when tampering is suspected.
17. Forensic Tools and Timestamp Interpretation
A question that runs through several of the studies already cited is whether the examiner is interpreting the original timestamp or interpreting a forensic tool's interpretation of it. Nordvik and Axelsson (2022) demonstrated this directly: given identical exFAT directory entries, Autopsy, X-Ways Forensics, EnCase and FTK Imager did not display uniformly consistent times, because the tools differed in how — or whether — they applied the UTC-offset field the specification provides for exactly this purpose. The authors' explicit conclusion was that timestamp interpretation in criminal investigations should not proceed on the assumption that either file-system drivers or forensic tools flawlessly implement the relevant specification. This argues for independent validation wherever a timestamp is central to a case theory: cross-checking a value across more than one tool, and where feasible, inspecting the raw artefact structure directly rather than relying solely on a single parser's rendered output, remains good practice precisely because parser assumptions and software versions are a documented, recurring source of silent error.
18. Metadata Is Not Truth: The Inferential Gap
The material reviewed above can be organised into a five-level structure describing the widening inferential gap between what a system stores and what an investigative narrative eventually claims. This structure is offered as a conceptual framework proposed for forensic discussion based on the literature reviewed in this article — it is not an existing international standard, and it should be read as a synthesis device rather than a citation to a settled taxonomy.
Level 1 — Timestamp Value
What the system stores: a raw numeric or binary value in a specific field, at a specific storage resolution.
Level 2 — Timestamp Semantics
What the technical system claims the value represents: the documented (or reverse-engineered) meaning of the field, as defined by the filesystem specification, API contract, or application schema.
Level 3 — Technical Event
What process most likely generated or last updated the value, established through controlled experimentation or reproduction of the suspected operation (e.g., Galhuber & Luh, 2021; Thierry & Müller, 2022).
Level 4 — User Activity Inference
What human action, if any, can reasonably be inferred from the technical event, given independent corroboration and an assessment of alternative explanations.
Level 5 — Investigative Narrative
How the inferred event is incorporated into a broader reconstruction of a sequence of events relevant to the matter under investigation.
The distance between Level 1 and Level 5 represents an increasing inferential burden that the examiner bears the responsibility of discharging explicitly, rather than by default.
19. The Difference Between Temporal Consistency and Temporal Proof
"The evidence is consistent with an event occurring at this time" and "the evidence proves the event occurred at this time" are propositions of fundamentally different evidential strength, and the forensic-science literature on evaluative reporting generally cautions against collapsing the two. Consistency is a necessary but not sufficient condition for proof: a recovered timestamp that aligns with a suspect's claimed alibi is consistent with that alibi being true, but it is equally consistent with a range of alternative explanations — clock error, timestamp inheritance from an earlier operation, or coincidental alignment — that a rigorous evaluation must consider and, where possible, exclude before treating the consistency as strong support for a single hypothesis (Gladyshev & Patel, 2004, 2005).
20. Error, Uncertainty and Confidence in Digital Time
Uncertainty enters a temporal reconstruction at multiple, cumulative points, and this review proposes organising them as a Temporal Uncertainty Propagation Model: Clock → Event → System Recording → Metadata Storage → Transformation → Synchronisation → Acquisition → Tool Interpretation → Examiner Conclusion → Investigative Narrative.
A confident conclusion reached at the end of this chain cannot automatically eliminate uncertainty introduced at an earlier stage — a perfectly executed forensic acquisition and a perfectly calibrated analysis tool cannot recover accuracy that was never present in the original clock reading, and a downstream correlation between two independently generated timestamps is only as strong as the weakest link in each of their respective chains. This review does not assign numerical uncertainty values to any stage, since the magnitude of clock drift, transformation error, or tool misparsing is case-specific and must be established empirically for the systems actually involved, as the exFAT and MACB compliance studies discussed above illustrate (Nordvik & Axelsson, 2022; Thierry & Müller, 2022).
Table 1 — Timestamp Meaning Across Digital Systems
| System/Artefact | Timestamp Field | Technical Meaning | Clock Source | Potential Forensic Ambiguity | Key Validation Consideration |
|---|---|---|---|---|---|
| NTFS $STANDARD_INFORMATION | Created / Modified / MFT-Modified / Accessed | User-mode-writable MACB set shown by Explorer and most tools | Local system clock, stored as UTC | Directly alterable by user-mode API calls ("timestomping") | Cross-check against $FILE_NAME and $LogFile (Galhuber & Luh, 2021) |
| NTFS $FILE_NAME | Created / Modified / MFT-Modified / Accessed | Kernel-written MACB set, not exposed via Explorer | Local system clock, stored as UTC | Rarely tampered with, but can appear "older" than $SI legitimately | Treat mismatches as investigative leads, not automatic proof of tampering |
| exFAT directory entry | Create / Modify / Access time + UTC offset | Local time with an offset field intended to enable UTC conversion | Device/OS local clock | Offset field applied inconsistently across Windows/macOS/Linux drivers and forensic tools | Verify tool-specific offset handling before relying on displayed time (Nordvik & Axelsson, 2022) |
| Ext4 / Unix-like (POSIX) | atime / mtime / ctime / (birth) | POSIX-defined access/modify/status-change semantics, birth time optional | Kernel clock, often NTP-disciplined | No tested OS fully POSIX-compliant; middleware (e.g., GIO) diverges from CLI utilities | Test the specific application/library actually used, not POSIX text alone (Thierry & Müller, 2022) |
| Cloud sync client (Dropbox/Drive/OneDrive) | Local file created/modified time post-sync | May reflect last cloud-side write, or local download time, depending on client vs. browser transfer | Mixed: client device clock and provider server clock | Browser downloads vs. client sync produce different local timestamp patterns for the same cloud file | Reproduce the specific transfer pathway experimentally (Quick & Choo, 2013a, 2013b) |
| Android SQLite application database | Application-defined epoch column | Defined entirely by the app's schema, not the OS | Device clock or remote server, depending on app architecture | Naive vs. UTC timestamps mixed within the same investigation | Establish schema version and normalise time zone before comparison (Kaart & Laraghy, 2014) |
| Browser history/cache entry | Visit/cache-write timestamp | Time the browser wrote the record, not necessarily the instant of user action | Local device clock | Documented multi-second delay between action and recorded timestamp; occasional URL mismatch | Report as an approximate window, not an exact instant (Groß, Dirauf, & Freiling, 2020) |
| EXIF image metadata | DateTimeOriginal / capture time | Camera/device capture instant, distinct from file-level timestamps | Camera/device internal clock | Frequently stripped or overwritten by messaging/social-media re-encoding pipelines | Confirm field survival through the actual transfer pathway before relying on it |
| System/application logs | Event/log timestamp | May mark generation, local write, transmission, receipt, or indexing | Local or remote clock, ideally NTP-disciplined | Buffering, rotation, and transmission delay can separate these sub-events by seconds or more | Identify which stage of the logging pipeline the field actually records (Kent et al., 2006) |
Table 2 — From Timestamp to Human Activity
| Timestamp Observation | Possible Technical Event | Possible Human Inference | Alternative Explanation | Required Corroboration |
|---|---|---|---|---|
| File "Created" time matches time of alleged offence | $SI creation write by an application, or by a copy/restore operation | Suspect authored the file at that moment | File was copied, restored from backup, or synchronised from another device at that moment | $FILE_NAME timestamp, $LogFile/USN Journal entries, or independent device history (Galhuber & Luh, 2021) |
| Browser history shows site visited at time t | Browser wrote a history record after page load completed | User clicked/typed the URL at time t | Automatic redirect, background refresh, or pre-fetch; or action occurred several seconds before t | Network logs, DNS records, or additional artefacts with independent timing (Groß et al., 2020) |
| Photo EXIF capture time places device at a location | Camera sensor recorded capture instant using its internal clock | Person was physically present at that location and time | Device clock was never set correctly; image was later edited/exported, altering associated file times | GPS metadata cross-check, cell-site or Wi-Fi records, independent witness or log data |
| Mobile app database shows message timestamp | Local write to SQLite table, possibly after network delay | Message was sent/received at exactly that instant | Value reflects server timestamp received later, or device clock offset from true time | Server-side records, carrier metadata, or cross-device comparison (Kaart & Laraghy, 2014) |
| Cloud file "Modified" time changes after collection | Download method (browser vs. client) reset or preserved timestamp differently | File content was altered by the user at the new time | Timestamp was regenerated purely as an artefact of the acquisition method itself | Hash comparison and documentation of exact collection method (Quick & Choo, 2013b) |
Table 3 — Sources of Temporal Uncertainty
| Stage | Potential Source of Error/Uncertainty | Possible Effect on Interpretation | Recommended Scientific Safeguard |
|---|---|---|---|
| Clock | Drift, manual misconfiguration, absent NTP discipline | All downstream timestamps shifted by an unknown, possibly non-linear offset | Establish clock correctness via independent time anchors (Willassen, 2008a; Vanini et al., 2024) |
| Event generation | Application buffering or delayed write-back | Recorded time lags true action time by a variable margin | Quantify typical delay experimentally for the specific software (Groß et al., 2020) |
| Metadata storage | Filesystem-specific rounding/truncation of resolution | Sub-second ordering may be lost or misleadingly implied | Confirm native storage resolution before relying on fine-grained ordering (Nordvik & Axelsson, 2022) |
| Transformation/synchronisation | Copy, move, cloud sync, backup/restore | Timestamp regenerated or inherited from an unrelated operation | Reproduce the alleged transfer pathway experimentally (Quick & Choo, 2013a, 2013b) |
| Acquisition | Collection method itself alters or resets metadata | Artefact of forensic process mistaken for case-relevant evidence | Document and, where possible, forensically validate the acquisition method's effect on metadata |
| Tool interpretation | Incorrect time-zone/offset handling by forensic software | Identical underlying bytes displayed as different times by different tools | Cross-validate across more than one tool and inspect raw structures where feasible (Nordvik & Axelsson, 2022) |
| Examiner interpretation | Collapsing "consistent with" into "proof of" | Overstated confidence in a single narrative over viable alternatives | Explicitly test and report alternative explanations (Gladyshev & Patel, 2004, 2005) |
21. Casework Representativeness and Validation
A persistent methodological challenge is that the digital ecosystem under study keeps changing while the validation literature necessarily lags behind it. Operating-system updates alter timestamp-handling behaviour (Thierry and Müller's 2022 finding that macOS's futimens() call sometimes fails to update timestamps as expected illustrates how such behaviour can vary even across versions of a single vendor's platform); mobile application updates change database schemas (Kaart & Laraghy, 2014); cloud services alter their synchronisation architecture without public notice; and forensic tools themselves are updated, sometimes changing parsing behaviour between versions. Reproducibility therefore requires examiners to document the exact software versions involved in both the original system and the analysis tools, and — where a timestamp interpretation is central to a case — to reproduce the relevant behaviour experimentally on matching versions rather than relying on a table published for an earlier release.
22. Cross-Disciplinary Lessons From Forensic Science
The broader forensic-science literature has long distinguished between source-level and activity-level propositions, and between a measured trace and the historical event used to explain it. Digital timestamp interpretation is a specific instance of that general problem: a recovered value is a measurement, and the human activity it is invoked to prove is an inference built on top of that measurement, mediated by assumptions about instrument calibration (clock correctness), measurement validity (semantic correctness of the field), and the availability of independent corroboration. The danger identified throughout this review — confusing a measured trace with the historical event it is used to infer — is not unique to digital evidence, but the layered, software-mediated nature of digital systems gives it unusually many opportunities to occur silently.
23. Major Research Gaps
24. Future Research Agenda
Priority 1 — Timestamp Semantic Validation Frameworks
Rationale: Recurring mismatches between documented specification and observed implementation (exFAT, POSIX) show that semantic validation cannot be assumed from documentation alone. Difficulty: Requires sustained, version-tracked experimental infrastructure. Importance: Directly reduces false-chronology risk. Limitation: Any framework will require continuous updating as software evolves.
Priority 2 — Cross-Platform Ground Truth Datasets
Rationale: Studies such as Groß et al. (2020) and Vanini et al. (2024) show the value of scripted, ground-truth-paired datasets. Difficulty: Scaling across device types, OS versions and applications is resource-intensive. Importance: Enables reproducible benchmarking of tools and methods. Limitation: Laboratory conditions cannot fully replicate real-world device histories.
Priority 3 — Cloud and Distributed System Time Research
Rationale: Server-side timestamp behaviour remains largely a black box to independent researchers. Difficulty: Dependent on provider cooperation or legal process for visibility. Importance: Growing share of casework involves cloud-resident evidence. Limitation: Findings may not generalise across providers or be stable over time as architectures change.
Priority 4 — Temporal Uncertainty Reporting
Rationale: No standard analogue exists to measurement-uncertainty reporting used elsewhere in forensic science. Difficulty: Requires consensus across a fragmented practitioner and research community. Importance: Would materially improve the transparency of evaluative reporting. Limitation: Numerical uncertainty is often not derivable without case-specific experimentation.
Priority 5 — Independent Tool Validation
Rationale: Demonstrated tool-to-tool inconsistency (Nordvik & Axelsson, 2022) shows parser behaviour is itself a variable requiring testing. Difficulty: Commercial tool internals are often closed-source. Importance: Central to reproducibility and defensibility of conclusions. Limitation: Vendor update cycles can outpace independent validation efforts.
Priority 6 — Mobile and Application Timestamp Research
Rationale: Application-specific SQLite schemas change frequently and are individually under-studied. Difficulty: High application churn requires continuous re-validation. Importance: Mobile artefacts dominate a large share of contemporary casework. Limitation: Findings are often application-version-specific and age quickly.
Priority 7 — Operational Timeline Reconstruction Studies
Rationale: Formal reconstruction methods (Gladyshev & Patel, 2004, 2005) exist but are not uniformly embedded in operational casework practice. Difficulty: Bridging formal methods and day-to-day investigative workflow requires tooling and training investment. Importance: Would reduce reliance on ad hoc, tool-default timeline views. Limitation: Formal rigor can be time-intensive relative to investigative deadlines.
Infographic: The Journey of a Digital Timestamp
25. Conclusion
Why is metadata not equivalent to truth? Because a timestamp is evidence generated by a system, not a direct transcript of an event — and every layer between a human action and a displayed number is a layer at which meaning can be preserved, transformed, or lost. Precision is not accuracy: a nanosecond-resolution value can be exactly wrong. Clock integrity matters, because no timestamp can be more trustworthy than the clock that produced it, and clock correctness is a claim requiring evidence rather than an assumption an investigation is entitled to make for free. Time-zone and UTC-offset interpretation matter, because the same underlying bytes can be rendered as different local times by different tools examining the identical disk image. Filesystem and application semantics matter, because a single human-readable label — "Created," "Modified" — can denote entirely different technical events depending on the system that wrote it. Transformation through copying, synchronisation, and cross-platform transfer matters, because these ordinary operations routinely regenerate or reset the very values an examiner is relying on to establish a timeline. And corroboration matters, because temporal consistency with a hypothesis is not proof of that hypothesis, particularly when equally plausible alternative explanations for the same artefact have not yet been tested and excluded.
None of this diminishes the evidential value of digital timestamps, which remain among the richest and most frequently decisive artefacts available to a digital investigation. It does mean that their evidential weight is earned rather than assumed. A timestamp that has been tested against its own filesystem's known behaviour, checked across more than one parsing tool, corroborated against an independent anchor, and evaluated against the alternative explanations it could equally support, carries a kind of evidential authority that a timestamp merely read off a screen does not. The most consequential error in a forensic timeline is rarely a timestamp that is technically false; it is far more often one that is technically correct, and asked — without that supporting work — to answer a question it was never built to answer.
Reference
Ayers, R., Brothers, S., & Jansen, W. (2014). Guidelines on mobile device forensics (NIST Special Publication 800-101 Rev. 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-101r1
Carrier, B. (2005). File system forensic analysis. Addison-Wesley.
Carrier, B. (2010). Different interpretations of ISO9660 file systems. Digital Investigation, 7, S129–S134. https://doi.org/10.1016/j.diin.2010.05.016
Casey, E. (2011). Digital evidence and computer crime: Forensic science, computers, and the internet (3rd ed.). Academic Press.
Chung, H., Park, J., Lee, S., & Kang, C. (2012). Digital forensic investigation of cloud storage services. Digital Investigation, 9(2), 81–95. https://doi.org/10.1016/j.diin.2012.05.015
Conlan, K., Baggili, I., & Breitinger, F. (2016). Anti-forensics: Furthering digital forensic science through a new extended, granular taxonomy. Digital Investigation, 18, S66–S75. https://doi.org/10.1016/j.diin.2016.04.006
Dreier, L. M., Vanini, C., Hargreaves, C. J., Breitinger, F., & Freiling, F. (2024). Beyond timestamps: Integrating implicit timing information into digital forensic timelines. Forensic Science International: Digital Investigation, 49, 301755. https://doi.org/10.1016/j.fsidi.2024.301755
Freiling, F., & Hösch, L. (2018). Controlled experiments in digital evidence tampering. Digital Investigation, 24, S83–S92. https://doi.org/10.1016/j.diin.2018.01.011
Galhuber, M., & Luh, R. (2021). Time for truth: Forensic analysis of NTFS timestamps. In Proceedings of the 16th International Conference on Availability, Reliability and Security (ARES '21), Article 44 (pp. 1–10). ACM. https://doi.org/10.1145/3465481.3470016
Galhuber, M., & Luh, R. (2024). Timestamp-based application fingerprinting in NTFS. In Proceedings of the 19th International Conference on Availability, Reliability and Security (ARES '24). ACM. https://doi.org/10.1145/3664476.3670890
Gladyshev, P., & Patel, A. (2004). Finite state machine approach to digital event reconstruction. Digital Investigation, 1(2), 130–149. https://doi.org/10.1016/j.diin.2004.03.001
Gladyshev, P., & Patel, A. (2005). Formalising event time bounding in digital investigations. International Journal of Digital Evidence, 4(2).
Göbel, T., & Baier, H. (2018). Anti-forensics in ext4: On secrecy and usability of timestamp-based data hiding. Digital Investigation, 24, S111–S120. https://doi.org/10.1016/j.diin.2018.01.014
Groß, T., Dirauf, R., & Freiling, F. (2020). Systematic analysis of browser history evidence. In 2020 13th International Conference on Systematic Approaches to Digital Forensic Engineering (SADFE) (pp. 1–12). IEEE. https://doi.org/10.1109/SADFE51007.2020.00007
Hargreaves, C., & Patterson, J. (2012). An automated timeline reconstruction approach for digital forensic investigations. Digital Investigation, 9, S69–S79. https://doi.org/10.1016/j.diin.2012.05.006
Kaart, M., & Laraghy, S. (2014). Android forensics: Interpretation of timestamps. Digital Investigation, 11(3), 234–248. https://doi.org/10.1016/j.diin.2014.05.001
Kent, K., Chevalier, S., Grance, T., & Dang, H. (2006). Guide to integrating forensic techniques into incident response (NIST Special Publication 800-86). National Institute of Standards and Technology.
Lamport, L. (1978). Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7), 558–565. https://doi.org/10.1145/359545.359563
Martini, B., & Choo, K.-K. R. (2013). Cloud storage forensics: ownCloud as a case study. Digital Investigation, 10(4), 287–299. https://doi.org/10.1016/j.diin.2013.08.005
Mills, D. L. (1991). Internet time synchronization: The network time protocol. IEEE Transactions on Communications, 39(10), 1482–1493. https://doi.org/10.1109/26.103043
Mills, D. L. (2003). A brief history of NTP time: Memoirs of an Internet timekeeper. ACM SIGCOMM Computer Communication Review, 33(2), 9–21. https://doi.org/10.1145/956981.956983
Nordvik, R., & Axelsson, S. (2022). It is about time – Do exFAT implementations handle timestamps correctly? Forensic Science International: Digital Investigation, 42–43, 301476. https://doi.org/10.1016/j.fsidi.2022.301476
Nordvik, R., & Axelsson, S. (2023). Corrigendum to "It is about time – do exFAT implementations handle timestamps correctly?" [Forensic Science International: Digital Investigation 42–43 (2022) 301476]. Forensic Science International: Digital Investigation, 45, 301542. https://doi.org/10.1016/j.fsidi.2023.301542
Nordvik, R., Georges, H., Toolan, F., & Axelsson, S. (2019). Reverse engineering of ReFS. Digital Investigation, 30, 127–147. https://doi.org/10.1016/j.diin.2019.07.004
Pieterse, H., Olivier, M., & van Heerden, R. (2015). Playing hide-and-seek: Detecting the manipulation of Android timestamps. In 2015 Information Security for South Africa (ISSA) (pp. 1–8). IEEE.
Quick, D., & Choo, K.-K. R. (2013a). Dropbox analysis: Data remnants on user machines. Digital Investigation, 10(1), 3–18. https://doi.org/10.1016/j.diin.2013.02.003
Quick, D., & Choo, K.-K. R. (2013b). Forensic collection of cloud storage data: Does the act of collection result in changes to the data or its metadata? Digital Investigation, 10(3), 266–277. https://doi.org/10.1016/j.diin.2013.07.001
Quick, D., & Choo, K.-K. R. (2013c). Digital droplets: Microsoft SkyDrive forensic data remnants. Future Generation Computer Systems, 29(6), 1378–1394. https://doi.org/10.1016/j.future.2013.02.001
Quick, D., & Choo, K.-K. R. (2014). Google Drive: Forensic analysis of data remnants. Journal of Network and Computer Applications, 40, 179–193. https://doi.org/10.1016/j.jnca.2013.09.016
Schneider, J., Eichhorn, M., & Freiling, F. C. (2022). Ambiguous file system partitions. Forensic Science International: Digital Investigation, 42, 301399. https://doi.org/10.1016/j.fsidi.2022.301399
Thierry, A., & Müller, T. (2022). A systematic approach to understanding MACB timestamps on Unix-like systems. Forensic Science International: Digital Investigation, 40, 301338. https://doi.org/10.1016/j.fsidi.2022.301338
Vanini, C., Hargreaves, C. J., van Beek, H., & Breitinger, F. (2024). Was the clock correct? Exploring timestamp interpretation through time anchors for digital forensic event reconstruction. Forensic Science International: Digital Investigation, 49, 301759. https://doi.org/10.1016/j.fsidi.2024.301759
Weil, M. C. (2002). Dynamic time & date stamp analysis. International Journal of Digital Evidence, 1(2).
Willassen, S. Y. (2008a). Hypothesis-based investigation of digital timestamps. In I. Ray & S. Shenoi (Eds.), Advances in digital forensics IV (IFIP International Federation for Information Processing, Vol. 285, pp. 75–86). Springer. https://doi.org/10.1007/978-0-387-84927-0_7
Willassen, S. Y. (2008b). Timestamp evidence correlation by model based clock hypothesis testing. In Proceedings of the 1st International ICST Conference on Forensic Applications and Techniques in Telecommunications, Information, and Multimedia. ICST. https://doi.org/10.4108/e-forensics.2008.2637
