File timestamps and what each clock field means

File timestamps record particular kinds of activity, with meanings and precision that depend on the operating system and file system.

A file does not have one universal “date.” Its timestamps record different events. A copy tool can preserve some of them, a file system can record them at limited precision, and an application can choose which ones to compare.

For Emby, those dates can contribute to library scanning or displayed file information. They do not replace the server's own playback history or identify every change to the content.

Which event does the field describe?

Field Usual meaning in the stated model What it does not establish
Linux mtime Last content modification When the file first entered this library
Linux ctime Last file-status change, including relevant metadata changes File creation time
Birth/creation time, where supported Creation of this file object Original release date or the age of copied content
Access time Access activity recorded under the platform's policy A complete record of who watched a film

Linux ctime is particularly easy to misread. A permissions or ownership change can update status-change time without changing the film's bytes. Birth time is a separate field and is not available through every file system or API.

A new copy can have an old modification time

Suppose a transfer finishes today but preserves the source's modification time from last year. The destination is newly created, yet its modification timestamp remains old.

An original comparison illustrates the consequence:

Previous observation: length 1,000,000 bytes; mtime 2026-09-01T12:00:00Z
Current observation:  length 1,000,000 bytes; mtime 2026-09-01T12:00:00Z

Those equal observations do not prove identical bytes. A tool could have preserved the time while replacing equal-length content. Detecting that replacement may require stronger evidence, such as a checksum, rather than only the two fields shown.

Precision and clock conventions

FAT's write timestamp has two-second resolution; its access field records a date. NTFS stores its timestamp values in UTC, while traditional FAT records local-time values. The field's storage precision and an application's displayed formatting are different issues.

For an illustrative two-second bucket, changes at 12:00:00.4 and 12:00:01.2 can map to the same bucket. A comparison at that precision cannot distinguish their order. Copying through a format with lower precision can also lose detail that existed on the source.

Do not interpret access-time updates as a playback counter: mount policies, delayed updates and operations unrelated to watching affect them. Incremental scanning uses file observations to decide what needs more work; those observations should retain the meaning and limits of their source fields.

See Also

References