Your Note's Created Date Is a Lie Waiting to Happen

The "Date created" your file manager shows is not a fact about your note. It is metadata the operating system keeps about the file, and a plain copy, a sync, or a backup restore can reset it to today without warning. If you sort by it, you trust a number the system owns. Write the date inside the file instead.

This is not a bug. It is what the timestamp was designed to mean. A volunteer moderator on Microsoft's Q&A forum put it plainly: "Date Created does not mean the Date you created the content. It means the date the file was first created on a given volume."¹

The forum threads where people discover this carry titles like "Creation Date and Dataview Dates are reset after copying/syncing :(".² The fix is small and durable: keep the date as a line of text in the note, where it travels with the words.

This post explains the footgun in concrete terms — how to read every timestamp, why a copy resets them, the three mistakes that cause the surprise, and where the date should actually live. The villain is not any app. It is the habit of trusting a fragile timestamp as your single source of truth.

What the dates actually mean

Every file carries up to four timestamps, and only one tracks creation. On Unix they are atime (last read), mtime (last content change), ctime (last status change), and a birth time set when the file is first written. The catch hides in ctime — it looks like "created" but means something else entirely.³

The confusion is almost always ctime. People see the "c" and read "created." It means changed. The Linux kernel manual is explicit: ctime "is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.)"³ — the last time the inode's metadata was touched, not the file's creation.

macOS draws the same line in its own documentation. ATTR_CMN_CHGTIME is "the time that the file system object's attributes were last modified," while the true creation time is a separate attribute, ATTR_CMN_CRTIME, "the time that the file system object was created."⁴

The four timestamps, in one place:

Birth time is the fragile one

Birth time is the timestamp closest to what you mean by "created," and the least reliable to count on. On Linux the classic stat call does not return it — you must request it through the newer statx call with the STATX_BTIME flag. The one date that means "created" is the one tools are least likely to keep.^{3 5}

The Linux manual marks birth time "(not returned in the stat structure)" and describes it as "The file's creation timestamp. This is set on file creation and not changed subsequently."³ The statx flag to request it is documented simply as "Want stx_btime."⁵

That opt-in design matters. Birth time is optional and filesystem-dependent — the kernel "may fail to return fields that were requested, depending on what the backing filesystem supports."⁵ Some filesystems record it; some do not. So the one timestamp that comes closest to a real creation date is the one a tool is least likely to preserve, and the one your filesystem might not store at all.

On macOS, stat does expose it. The command surfaces "the birth time of the inode" alongside access, modify, and inode-change times.⁶ That makes macOS a good place to see the footgun — which the next section does, with a live demonstration.

See the reset for yourself

Run a few commands and a plain copy rewrites every date. On macOS, create a file, copy it normally, then copy it again with timestamp preservation, and read the dates back. The plain copy stamps a brand-new birth, modify, and change time. The "preserve" copy keeps modify and birth, yet the change time still moves — the kernel stamps it.

echo "hello" > note.md
stat -f 'name=%N birth=%SB mtime=%Sm ctime=%Sc' note.md
# name=note.md birth=Jun 26 22:32:26 mtime=Jun 26 22:32:26 ctime=Jun 26 22:32:26

cp note.md note-copy.md          # a plain copy
stat -f 'name=%N birth=%SB mtime=%Sm ctime=%Sc' note-copy.md
# name=note-copy.md birth=Jun 26 22:32:27 mtime=Jun 26 22:32:27 ctime=Jun 26 22:32:27

cp -p note.md note-pcopy.md      # "preserve" copy
stat -f 'name=%N birth=%SB mtime=%Sm ctime=%Sc' note-pcopy.md
# name=note-pcopy.md birth=Jun 26 22:32:26 mtime=Jun 26 22:32:26 ctime=Jun 26 22:32:27

The original was created at 22:32:26. The plain copy reads 22:32:27 on all three — the original date is gone. The cp -p copy keeps the original modify and birth time, but its change time still jumps to 22:32:27, because no system call sets ctime directly; the kernel always stamps it on any write.⁷ Multiply that one second by a folder of a thousand notes copied during a migration, and every "date created" now reads the day you migrated.

Why a copy, a sync, or a restore rewrites the date

A copy does not move your file — it writes a new one. The new file gets a fresh birth and modify time, because to the system it is new. Windows File Explorer resets "Date created" on a cross-volume copy; a default cp does the same. A sync client downloads a fresh copy on the second device, with today's date.

Tools can opt back in, but it is always opt-in. The same moderator notes you "will need to use a tool such as RoboCopy or FastCopy to keep the original Date created when copying to another volume."¹ On Linux, rsync preserves modification time only with --times (-t); to also carry the creation time you need a separate flag, "--crtimes, -N preserve create times (newness)."⁸ The behavior of common operations:

The pattern is consistent across every system: preserving the date is the exception you have to ask for, and the cloud-sync GUI most people actually use rarely exposes the option. That is precisely why the date you control should not live in metadata at all.

Common mistakes

Three assumptions cause almost every "why did my note dates reset" surprise: that ctime means "created," that a copy keeps the date, and that sync preserves it. Each is reasonable, and each is wrong in the same way — it shows up only after a migration, when every note suddenly reads today's date.

• Trusting ctime as the creation date. The "c" is for changed, not created. On Unix, ctime is the last time the inode's metadata changed; a permission edit or a rename moves it. macOS calls the same field "attributes were last modified."^{3 4} Windows NTFS does keep a separate true creation timestamp, but the Unix ctime is not it.
• Assuming cp preserves dates. A default copy creates a new file with new timestamps. Even cp -p, which keeps modify and birth time, still bumps the change time, and birth time is not guaranteed to survive across different filesystems.⁷
• Relying on sync to keep the original date. Sync clients write a fresh file on the receiving device. Unless the tool specifically opts into preserving creation time — and most GUIs do not — the synced copy is stamped with the sync date, which is the exact complaint in the "Preserve Creation Dates when Using Obsidian Sync" threads.⁹

Put the date inside the file

The durable fix is to stop relying on metadata and write the date as text in the note. A written date is part of the file's contents, so it survives every copy, sync, and restore — the operations that rewrite a timestamp leave it untouched. The date you control belongs in the file, not in metadata the system owns.

One Obsidian practitioner reached the same conclusion after the reset bit them: "include a cdate (or similar) field in the note's front matter and just direct the Dataview query against that."¹⁰

There are two good homes for the date — and they complement each other.

The first is YAML frontmatter, a small block of key: value lines at the top of the file. Put created: and updated: there and every tool that reads the note can sort by them, because the date is now content — not metadata. The mechanics of frontmatter are their own topic; see how YAML frontmatter adds structure without a database for the full pattern.

---
created: 2026-06-26
updated: 2026-06-26
---

# Meeting notes

The second home is the filename. A note named 2026-06-26-meeting-notes.md carries its date in a form that survives any copy and sorts correctly in any file listing, on any system. That is a deliberate practice in its own right — see how to name your note files so you can still find them in 20 years. Frontmatter is the queryable home; the filename is the at-a-glance one. Use either, or both.

This is the deeper logic behind keeping notes as plain Markdown files on your own device, as MNMNOTE does: when the note is a file you own, the meaningful facts about it — including when — can live inside the file, where no system controls them and no copy can rewrite them.

An honest caveat

Filesystem dates are not useless. They are genuinely helpful day to day — "recent files," "sort by modified," and the quick scan of what you touched this morning all rely on them, and they work fine for that. The argument here is narrower and more honest than "never trust timestamps."

The rule is simply this: do not rely on a filesystem timestamp as your single source of truth for when something happened. Let the OS keep its working dates for convenience. Keep the date that matters as text you own, inside the file, so that when a copy or a sync inevitably rewrites the metadata, the real answer is still right there in the note.

Frequently asked questions

These are the questions people search when their note dates surprise them — what each timestamp means, why a copy or a sync rewrites it, and how to read or preserve the real one. The short version runs through every one: the date you can trust is the date you wrote into the file.

Does copying a file change the date created?

Usually yes. A default copy writes a new file, so it gets a new birth time and a new modify time set to the moment of the copy. Windows Explorer resets "Date created" when copying across volumes. Only opt-in tools — cp -p, rsync --crtimes, robocopy /DCOPY:T, TeraCopy, FastCopy — carry the original date over.

What is the difference between mtime, ctime, and birthtime?

mtime is the last time the file's contents changed. ctime is the last time the inode's metadata changed — permissions, ownership, a rename, or a write — not the creation time. Birth time (btime, or crtime on macOS) is when the file was first created. atime, a fourth timestamp, records the last read.

Is ctime the creation date?

No. On Unix systems, ctime stands for change time, not create time. The Linux manual defines it as the last status change, "changed by writing or by setting inode information."³ macOS labels the equivalent field as when attributes "were last modified."⁴ Windows NTFS keeps a separate true creation timestamp, but the Unix ctime is not it.

Why did my note dates reset after a sync?

Because the sync wrote a fresh copy on the second device, and to the operating system a fresh copy is a new file with a new date. Most sync clients do not preserve the original creation time, so every synced note can show the sync date. Writing the date into the file's frontmatter or filename avoids this entirely.

How do I read all four timestamps?

On macOS, stat -x note.md shows access, modify, change, and birth times. On Linux, stat note.md shows access, modify, and change; for birth time you need stat --format=%w or a statx-based tool, and only on filesystems that record it.^{5 6}

How do I keep the date created when copying files on Windows?

File Explorer resets it, so use a tool that preserves timestamps: robocopy /DCOPY:T from the command line, or a GUI like TeraCopy or FastCopy configured to replace Explorer's copy function.¹ More durably, write the date into the file itself so no copy tool can lose it.

A file's metadata belongs to the system that holds it; the file's contents belong to you. Write the date where you can still read it after the metadata is gone — and the next migration becomes a non-event.

This builds on Steph Ango's "file over app" idea — that "the files you create are more important than the tools you use to create them."¹¹

To keep the date among the things that last, it lives in a file you own at mnmnote.com.