Introduction

Getting a file’s timestamps sounds simple, but there are two separate questions hiding underneath. The first is how to read the metadata in your language or tool of choice. The second is whether the underlying operating system and file system actually provide the timestamp you want.

Modification time is widely available. Creation time is not as portable. On Unix-like systems, the field people often grab by mistake is sometimes metadata change time rather than true file creation time.

The Main Timestamps to Know

Most file metadata discussions involve three timestamps:

• modification time, usually called mtime
• access time, usually called atime
• metadata change time, often called ctime

The confusing one is ctime. On many Unix systems, it is not creation time. It is the time when file metadata last changed, such as permissions, ownership, or link count.

Some platforms also expose a true creation time, sometimes called birth time.

Reading Timestamps in Python

Python makes file metadata easy to inspect with pathlib or os.stat.

1from pathlib import Path
2from datetime import datetime
3
4path = Path("example.txt")
5stats = path.stat()
6
7modified = datetime.fromtimestamp(stats.st_mtime)
8accessed = datetime.fromtimestamp(stats.st_atime)
9
10print("Modified:", modified)
11print("Accessed:", accessed)

That is portable for modification and access times. Creation time is where you need to be more careful.

Dealing with Creation Time Portability

On Windows, st_ctime has traditionally represented creation time. On many Unix-like systems, st_ctime is metadata change time instead. Some systems, such as macOS and some BSD variants, expose st_birthtime for true creation time.

A practical cross-platform helper looks like this:

1from pathlib import Path
2from datetime import datetime
3import platform
4
5
6def file_times(path_str: str) -> None:
7    path = Path(path_str)
8    stats = path.stat()
9
10    modified = datetime.fromtimestamp(stats.st_mtime)
11    print("Modified:", modified)
12
13    if hasattr(stats, "st_birthtime"):
14        created = datetime.fromtimestamp(stats.st_birthtime)
15        print("Created:", created)
16    elif platform.system() == "Windows":
17        created = datetime.fromtimestamp(stats.st_ctime)
18        print("Created:", created)
19    else:
20        print("Created: not available on this platform")
21
22
23file_times("example.txt")

This is safer than assuming one field means the same thing everywhere.

Shell Tools for Quick Inspection

Sometimes you do not need code at all. A shell command is enough to inspect the values quickly.

On macOS:

stat -x example.txt

On Linux:

stat example.txt

These commands are useful when you want to verify what the file system is actually exposing before writing code around it.

File-System Reality Matters

Even if your language runtime exposes a creation-time field, the file system may not store it or may present different semantics depending on the mount, platform, or copy operation used.

That means two files can behave differently even under the same application code if:

• they live on different file systems
• they were copied by tools that reset metadata
• the platform does not preserve birth time

This is why timestamp logic should be designed around the exact guarantee you need. If you only need to know when file contents last changed, mtime is usually the correct and portable answer.

When You Need Stable Time Logic

If your application depends on creation time for auditing or business rules, do not assume the file system is the source of truth. A database record or application-level metadata store is often more reliable than platform-dependent file attributes.

File timestamps are convenient, but they are not always durable enough to define application semantics on their own.

Common Pitfalls

The most common pitfall is treating Unix ctime as creation time. On many systems it means inode metadata change time, which can update when you modify permissions even if the file contents stay the same.

Another issue is testing on one platform and deploying on another. Code that appears to work on Windows can behave differently on Linux or macOS because the timestamp fields do not map the same way.

It is also easy to forget timezone handling when printing timestamps. Most APIs return epoch values, and your formatting code determines how they are displayed.

Finally, be aware that copying, extracting archives, or syncing files through cloud tools may change timestamp values in ways that surprise downstream logic.

Summary

• Modification time is portable and widely available; creation time is not.
• On many Unix-like systems, ctime means metadata change time, not creation time.
• Use os.stat or pathlib.Path.stat() to read timestamps in Python.
• Check for st_birthtime where available and treat Windows st_ctime carefully.
• If creation time is business-critical, store it explicitly rather than trusting file-system metadata alone.