timestamps

Overview

Every log entry and file carries timestamps, and getting time right — and understanding time zones — is essential to reconstructing when things happened. In investigations, accurate timelines depend entirely on timestamps. This lesson covers time and timestamps on Linux.

Learning objectives

• Explain timestamp formats and time zones on Linux.
• Interpret file timestamps (atime, mtime, ctime).
• Appreciate why accurate time is critical to forensics.

Core concept

Time on Linux involves a few key ideas:

• UTC vs local time — systems (and especially logs) often use UTC to avoid ambiguity; understanding the offset to local time is essential when correlating events.
• File timestamps — each file has an atime (last access), mtime (last modification of contents), and ctime (last change of metadata/inode). ls -l shows mtime by default; stat <file> shows all three.
• Time synchronization — services like NTP/systemd-timesyncd keep the clock accurate.

How it works

Logs record when events happened; stat reveals when a file was last read, modified, or had its metadata changed. To build an accurate timeline, all these times must be interpreted consistently — which requires knowing the system's time zone and whether logs are in UTC. If the system clock is wrong or unsynchronized, every timestamp is unreliable, corrupting any timeline. This is why NTP synchronization is a baseline requirement, particularly across multiple systems whose logs must be correlated.

Practical example

$ stat report.txt
Access: 2026-09-21 10:05:00
Modify: 2026-09-20 18:30:00
Change: 2026-09-20 18:30:00
$ date -u
Mon Sep 21 10:20:00 UTC 2026

stat shows the file was last read on Sep 21 but last modified on Sep 20. date -u confirms the current UTC time. In an investigation, comparing a file's mtime to log events (in the same time reference) helps establish what changed and when.

Cybersecurity relevance

Timestamps are the foundation of forensic timelines: reconstructing an incident means ordering events across logs and files precisely. Accurate, synchronized time (and knowing the UTC offset) is what makes cross-system correlation valid — a skewed clock can make an attack appear to happen at the wrong time or break the sequence entirely. Note that timestamps can be manipulated by an attacker (e.g. altering mtime to hide changes), so investigators corroborate them with other evidence. Consistent time is also required for meaningful log correlation in a SOC.

Common mistakes

• Confusing atime/mtime/ctime — access vs content-modification vs metadata-change times.
• Ignoring time zones / UTC, misaligning events when correlating logs across systems.
• Trusting a timestamp blindly — clocks can be wrong and timestamps can be tampered with.

Key takeaways

• Linux uses UTC and local time; logs often use UTC, so knowing the offset matters for correlation.
• Files have atime (access), mtime (content modification), and ctime (metadata change); stat shows all three, ls -l shows mtime.
• Accurate, synchronized time (NTP) underpins forensic timelines and cross-system correlation; timestamps can be manipulated, so corroborate them.

Check your understanding

• What is the difference between a file's mtime and its ctime?
• Why is synchronized, accurate system time essential when correlating logs across multiple machines?