A designer messages a client: I built this concept in March, you copied it in June. The client asks for proof. The designer sends three things: a screenshot of a project folder with a date, a forwarded email from March, and a file whose properties read "Date modified: March 14." The client's lawyer looks at all three and asks one question. Who controls that date. The answer is the designer, and that answer is the whole problem.
The screenshot
A screenshot is a picture of what a screen showed at the moment someone took it. It proves the picture exists. It does not prove the file behind it existed on the date the screenshot displays, because the system clock that produced that date belongs to whoever holds the machine. Change the clock, take the screenshot, change it back. Nothing in the image records that this happened, and nothing about a screenshot needs to, because it was never built to survive that kind of question in the first place.
The email
An email carries a header with a date generated by mail servers you do not personally control, which looks like an improvement over a screenshot. It is a partial one. The server records when a message passed through it, not what the attached file actually contained, and not whether the file now being produced as evidence is the same one that travelled in that message. Threads get forwarded, saved locally, reopened and re-attached, and each of those steps can quietly swap the file without touching a single visible date in the conversation. A header proves a message moved through a system at a point in time. It does not bind that time to the exact bytes of the document you are holding up now.
The file's own date
"Date modified" and "date created" are properties the operating system keeps about a file, not properties the file carries with it. Copy the file to another drive, sync it through a cloud folder, or simply open and resave it, and those dates frequently reset to whenever that action happened, sometimes to the same afternoon someone needed to produce evidence. Anyone with ordinary access to the file system can also set them directly with a standard utility, no special skill required. This is not a flaw in any particular operating system. It is what happens when a claim and the record of that claim sit on the same machine, controlled by the same party who benefits from the date reading a certain way.
Having the original file does not fix this
A common instinct is to think possession settles the argument: I still have the file, so I must have made it. Possession proves you have a copy today. It says nothing about when that copy, or any earlier version of it, first existed, because a file on your own drive carries no independent record of its own history. The file and the claim about its age come from the same source, which is exactly the weakness a dispute exposes.
The pattern underneath all four
Each of these records fails for the same structural reason, not because anyone involved is lying. Most disputes involve two people who each genuinely believe their own version of events. The date lives in a system one party controls, and it can be changed by that party or altered by ordinary use, without leaving any trace that it happened. A date you generated is a date you can be asked to justify, and "trust me" is not something a court, a client, or a licensing platform can act on when money or credit is on the line.
What a qualified timestamp does differently
A qualified electronic timestamp does not describe a file. It is bound to one, cryptographically. A hash is computed from the exact bytes of the file, and a Qualified Trust Service Provider issues the timestamp over that hash, not over a filename, a folder path, or a written description. Change one character in the document and the hash no longer matches, so there is no ambiguity later about which version was sealed.
Under eIDAS, a qualified electronic timestamp carries a legal presumption as to the date and time it indicates and the integrity of the data it is bound to. That presumption exists precisely because the date was not generated by either side of a future dispute. It came from a regulated third party whose entire function is issuing timestamps that neither party can quietly edit afterward.
This does not create the underlying right, and it is worth being precise about that. Under the Berne Convention, copyright arises automatically at the moment a work is created, in over 180 countries, with no registration or formality required. A timestamp does not grant that protection, and it does not need to. What it gives you is evidence of when a specific version of a specific file existed, which is the exact question that a screenshot, an email, or a file's own metadata cannot answer once somebody who was not in the room asks it directly.
What survives an actual question
The difference stops being abstract once you compare what each record can withstand. A screenshot survives a casual glance and fails the first direct question about the system clock. An email survives until someone asks for the original attachment rather than the forwarded copy sitting three messages deep. A file's modified date survives until the file is copied anywhere at all. A record built around a qualified timestamp is designed for the opposite situation: it is meant to be checked by someone who was not in the room and has no reason to take your word for it. A public verification page confirms the hash, the declaration and the timestamp, without an account and without needing to contact whoever is making the claim.
That last part is a fair test to run on your own evidence right now. Hand your screenshot, your email and your file properties to someone genuinely skeptical, and ask them to confirm your claim without asking you anything further. None of the three gets there by itself.
Beyond a courtroom
The same weak evidence shows up outside a courtroom too. A licensing platform, or a company evaluating whether content was used without permission, runs into the identical problem: a screenshot or a claimed creation date proves nothing about a file's real history and cannot be checked against anything else at scale. A cryptographic hash serves a related need there. Because it is derived from a file's exact content rather than a description of it, the hash can be compared against other content without ever exposing the original file. That property is what makes a record useful for tracing where content has been used, not only for winning an argument about who made it first.
Building the habit instead of the archive
The fix is not reconstructing years of old work into a single afternoon of proof-gathering. It is changing what happens at the moment something is finished. Sealing a file takes a few minutes and produces a record built from a cryptographic hash, a declaration of how the work was made, and a qualified timestamp, backed by a verification link anyone can open independently. Do this at the point of publication or delivery going forward, and the next dispute starts from a record designed to answer the question, rather than a folder of files whose dates you would have to explain one at a time.
