A scanned agreement arrives carrying four different dates. The PDF says it was created in March. The folder it sits in is named for the previous year. Its modified time is last Tuesday, because somebody opened it to check a clause. The scanner’s own clock said whatever it said, and nobody has looked at that clock in three years.
None of those dates disagree because somebody lied. They disagree because they were written at different moments by different software, and because a file carries more than one idea of when.
This post is about what each of those dates is, how each one gets rewritten, and what an examiner can actually say when two of them disagree. The answer to that last question is narrower than people expect, and it cuts in both directions. If what you want is the remedy rather than the mechanism, that is a different post about proving when a document existed .
What a Scan Actually Records
A file carries dates in two places that do not talk to each other.
Inside the PDF, a document information dictionary holds a creation date and a modification date as plain text. PDF 1.4 and later also carry a separate XMP metadata packet with its own create, modify and metadata dates. These are two parallel records of the same idea, maintained separately, and nothing in the format requires them to agree.
Outside the PDF, the filesystem keeps its own set. NTFS stores its times in UTC, while FAT stores them in the local time of the machine that wrote them, so the same file copied between two volumes can display two different times without anything having been altered [1 ]. The same documentation notes that NTFS delays updating a file’s last access time by up to an hour, and that a last write time is not fully updated until every handle used for writing is closed. A date that is late by design is not, by itself, evidence of alteration.
Six or seven values, then, every one of them written by the equipment that produced and stored the file.
Every One of Those Dates Can Be Rewritten
Each field can be set to an arbitrary value with free, documented tooling. What follows pairs each mechanism with the artifact an examiner would look for, because a mechanism without its detection artifact is half an answer.
Filesystem dates on Unix-like systems. A standard utility on every such system sets a file’s access and modification times to any value you name [2 ]. It does not set the inode change time, because the kernel writes that itself whenever the record changes. That makes the field harder to reach rather than beyond reach, and a change time later than the modification time is the first thing an examiner looks at. But it is also exactly what an ordinary copy or a backup restore produces. It raises a question rather than answering one.
Filesystem dates on Windows. This is not a hack and it does not need one. Microsoft documents an API whose stated purpose is to “modify creation, last access, and last write times without changing the content of the file” [1 ]. Any program may call it. Backup software, synchronization clients and archive extractors all do, for ordinary reasons.
PDF dates. A widely used metadata tool rewrites both the dictionary and the XMP dates in one pass, and its own documentation says what that leaves behind: the tool appends rather than replaces, so the prior values can survive in the file, and it calls that a potential security problem because old information is never actually deleted from the file [3 ]. Where those prior values survive, they are the most direct record in the file of what the dates used to say. Their absence establishes nothing, because ordinary processing may leave no such history at all.
The two PDF records against each other. Because the dictionary and the XMP packet are maintained independently, a PDF claiming one year in one and another year in the other is worth asking about. It is an indicator rather than a finding: some editors legitimately update one and not the other. It is the cheapest check here, and cheap is not the same as conclusive.
The two NTFS timestamp sets against each other. Windows keeps two independent sets per file record, and ordinary user-mode calls reach only one of them, so a disagreement between the two is worth examining. It is proof of nothing on its own. Copies, archive extractions, backup restores and a good many installers produce that disagreement innocently, and a rename or a same-volume move copies the values across and removes the disagreement altogether, so its absence is not informative either. What an examiner leans on instead is corroboration: sub-second precision that has been zeroed where it should be noisy, and the records the volume keeps elsewhere.
The clock itself. A machine with no verified time source writes whatever its local clock says into every field it touches, and this is the one that leaves no tidy artifact inside the file. It does not mean the act is invisible. It means the file on its own may not show it. What does show it is elsewhere, and that is the next section.
What the File Cannot Tell You By Itself
Ordinary copying creates a new file with new dates. An entirely honest chain of scan, save, email, download and re-save produces a cascade of later timestamps with nothing wrong in it. Filesystem dates are weak standing alone, absent corroboration from records kept somewhere else, and they are weak in both directions: they will not establish a date and they will not defeat one.
What does the corroborating is the set of records nobody edits on purpose because nobody thinks about them. A clock that was moved leaves traces in system event logs, in the volume’s change journal, in the ordering of unrelated files written during the same session, and in the synchronization records of any cloud client that was running. Those records are kept by different software for different reasons, and the reason they are worth more than the file’s own dates is not that they are harder to alter. It is that altering all of them consistently is a different and much larger job than altering one. Several of those records are finite. NTFS trims its change journal from the front once the journal grows past the size it was created with [4 ], and cloud clients age out their history on schedules of their own, so some of the records that would settle a date question are themselves perishable.
An examiner who offers you a timestamp disagreement and nothing else has given you an observation. An examiner who offers you the same disagreement plus two independent records that agree with it has given you something else.
If the Document Is Already in Front of You
If somebody hands you a PDF and a date, these are the questions that separate a checkable claim from an assertion. An examiner would need each of them answered to assess the claim.
Where does the date come from, field by field? An answer of “the file properties” has named a source that is easily rewritten and carries no independent corroboration.
Do the information dictionary and the XMP packet agree, and does anyone know whether they were asked? This costs a minute and is skipped constantly.
Is there a record of this document anywhere outside the custodian’s own control at the relevant time? A mail record, a platform audit trail, a provider log, a timestamp token. An answer here moves the analysis further than anything else on this list.
If a timestamp disagreement is offered as evidence of manipulation, what corroborates it outside the file record?
Has anyone checked whether a rename, a restore or an ordinary copy would explain that same disagreement?
Was the machine’s clock verified against an external time source, and is there a record of that check? If the answer is no, every date that machine wrote inherits that.
What to Take From This
A document’s dates are a starting point and not a conclusion. Every one of them was written by equipment somebody in the matter controls, most of them can be set deliberately with documented tools, and several of them move for innocent reasons that look identical to deliberate ones.
That is not a counsel of despair. It is the reason the remedy exists, and the remedy is to put the record of when into a system nobody in the argument controls. Two companion posts cover that: proving when a document existed surveys who can hold that record, and how to timestamp a document is the method, end to end.
Lucid Truth Technologies examines documents and the records that surround them, tests what the metadata is claimed to prove, and says plainly where the record runs out. If a matter in your office turns on when a document existed, contact us to discuss it.
References
Vendor and operating system behavior described in this post was verified in September 2026 and may have changed since.
[1] Microsoft Corporation, “File Times,” Win32 apps documentation. [Online]. Available: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times
[2] Linux man-pages project, “touch(1): change file timestamps.” [Online]. Available: https://man7.org/linux/man-pages/man1/touch.1.html
[3] P. Harvey, “PDF Tags,” ExifTool Tag Names. [Online]. Available: https://exiftool.org/TagNames/PDF.html
[4] Microsoft Corporation, “Creating, Modifying, and Deleting a Change Journal,” Win32 apps documentation. [Online]. Available: https://learn.microsoft.com/en-us/windows/win32/fileio/creating-modifying-and-deleting-a-change-journal
