People often point to a file’s date as if it were a fact about the file. In reality the date is a note the operating system keeps, and ordinary actions such as copying, zipping or downloading rewrite it. To show this with real numbers rather than general claims, we ran a small set of tests on a Linux machine and recorded what happened to each date, and to the file’s SHA-256 fingerprint.
Disclosure: I’m Inna Hall, co-founder of TimeBinder, the file timestamping tool this guide uses. This page is general information, not legal advice.
Table of Contents
The dates a file has
- Modified (mtime): when the contents were last written. This is the date most apps show.
- Created or birth time: when this copy of the file was created on this disk. Windows (NTFS), macOS (APFS) and modern Linux file systems such as ext4 record it.
- Changed (ctime, Linux and macOS): when the file’s metadata, such as its name or permissions, last changed.
- Accessed: when it was last read, often updated lazily or not at all.
None of these belong to the file’s contents. They live in the file system, which is why they behave so differently from the fingerprint.
How we tested
Test method, stated in full: on 29 October 2026 we ran the tests on a Linux virtual machine (ext4 file system, Linux kernel 6.12, GNU coreutils 9.7, which reads birth time). The time zone was set to Australia/Brisbane (UTC+10) except where noted. We created one small text file, waited a few seconds between steps so time differences were visible, and after each action recorded the birth time, modified time and SHA-256 hash with standard tools. Zip archives were made with Python’s zipfile module, which writes no extended timestamp field, and extracted with Info-ZIP unzip. Downloads were served from a local web server. These results describe this setup only. Other operating systems, file systems and apps can behave differently, and we have not tested Windows or macOS here.
Results
The original file was created at 10:10:33 AEST. “New” means the date became the time of the action.
| Action | Birth (created) time | Modified time | SHA-256 fingerprint |
|---|---|---|---|
| Plain copy (cp) | New (copy time) | New (copy time) | Same |
| Copy preserving attributes (cp -p) | New | Kept | Same |
| Move within the same disk (mv) | Kept | Kept | Same |
| Re-write contents into a new file | New | New | Same |
| tar archive, then extract | New (extract time) | Kept | Same |
| zip, then unzip (Brisbane time zone) | New | Kept, rounded to 2 seconds (10:10:33 became 10:10:32) | Same |
| Same zip, unzip with New York time zone | New | Shifted 14 hours later | Same |
| Same zip, extracted with Python’s zipfile module | New | New (not restored) | Same |
| gzip, then gunzip | New | Kept | Same |
| Download over HTTP (curl, default) | New | New (download time) | Same |
| Download asking to keep the server’s date (curl -R) | New | Server’s Last-Modified date | Same |
| git clone | New (checkout time) | New (checkout time) | Same |
| git archive of a commit, then extract | New | Commit time | Same |
| Append one line to the file | Kept | New | Changed |
Three things stand out:
- Created dates are the least stable. Every action that produced a new copy gave it a new birth time, even when the modified time was kept. A “created” date later than the “modified” date is normal for a copied file.
- Zip files can shift times by hours. Because the zip format stores local time without a zone (unless an extra field is added), the same archive gave different modified times depending on the time zone of the computer that extracted it. Times were also rounded to an even number of seconds.
- The fingerprint never moved until the content did. Thirteen different handling steps left the SHA-256 hash unchanged. Adding a single line changed it completely. The same fingerprints can help catch silent disk corruption; see whether ext4 checksums your file data.
What happens on Windows, macOS and email
We did not test these here, but some behaviour is well documented:
- Windows: copying a file in File Explorer typically sets a new Date created and keeps Date modified. Moving it within the same drive keeps both. Files downloaded by browsers are usually tagged with a “Mark of the Web” (a Zone.Identifier stream) that can record where they came from.
- macOS: downloaded files usually get a quarantine attribute, and Spotlight can record the download source. Different copy tools preserve different dates.
- Email: attachments normally arrive without their original file system dates. The MIME standard allows creation and modification dates on an attachment, but they are rarely used, so a saved attachment usually gets the date you saved it.
- Cloud sync: desktop sync clients often keep the modified time, while downloading from a web interface may not. It varies by service.
For why these dates are also easy to edit deliberately, see can a file’s date created be changed?.
What this means if you need to prove a date
File dates are useful clues about your own workflow, but they record what happened to a particular copy, not when the content first existed, and they shift through ordinary handling. The content’s fingerprint is stable. That is why timestamping works on the fingerprint: TimeBinder records a file’s SHA-256 hash on the Bitcoin blockchain, so anyone can later re-hash the file and check that it existed no later than the recorded time, however many times it was copied, zipped or downloaded since.
Related: why a file’s dates disagree, how to prove a file existed before a date and the free SHA-256 file hash checker.
Which plan fits
The free plan gives you 1 Token a month, which is one Pooled TimeBind of up to 10 files. No credit card is required for the free plan. A Pooled TimeBind is usually recorded within 24 to 48 hours, and often sooner, depending on Bitcoin network activity; an ASAP TimeBind costs 3 Tokens and gets its own Bitcoin transaction straight away.
For more milestones, Essential is US$20 a month for 5 Tokens (5 Pooled, or 1 ASAP plus 2 Pooled). Expert is US$50 a month for 15 Tokens (15 Pooled or 5 ASAP). On Essential and Expert, unused Tokens roll over every month, and a paid plan replaces the Free plan’s monthly Token. Verification is free. See pricing.
What a timestamp does and doesn’t do
TimeBinder anchors each file’s SHA-256 fingerprint to Bitcoin and gives you a Proof of Time Certificate. That is verifiable evidence of when a file existed: it shows the file existed no later than the anchor date, and any later change to the file is detectable. An ASAP TimeBind can be checked directly on the Bitcoin blockchain without relying on TimeBinder; a Pooled TimeBind is verified through TimeBinder. Your file is hashed in your browser and never uploaded.
It doesn’t show who made the work or who owns it, it doesn’t stop copying, and it doesn’t cover a version you didn’t timestamp. It also cannot recover the date of a file you never timestamped. Only records made at the time can do that.
Frequently Asked Questions
Does copying a file change its date?
Usually one of its dates. In our Linux test a plain copy got a new created (birth) time and a new modified time; a copy that preserves attributes kept the modified time but still got a new birth time. On Windows, copying in File Explorer typically gives the copy a new Date created but keeps Date modified.
Why does a file look older or newer after I unzip it?
Zip archives store each file’s modified time in local time with 2-second precision and, unless an extra field is present, no time zone. In our test the same zip extracted with a New York time zone setting showed a modified time 14 hours later than when extracted in Brisbane.
Does downloading a file keep its original date?
Often not. In our test a default download got the download time as both its birth and modified time. Browsers and download tools differ, and some can keep a server’s date.
If the dates change, how can anyone tell it is the same file?
By its fingerprint. The SHA-256 hash stayed identical through every copy, move, archive, download and clone in our test, and changed only when we edited the content. A timestamp records that fingerprint, so the date of the record doesn’t depend on file dates at all.
Plan details were checked against timebinder.io/pricing on 29 October 2026.
