1 Timestamps, UTC & ISO 8601
Consider 2026-08-30 10:15:32. What timezone is this? UTC, GMT, BST, CET, CEST, EST, EDT, server local time, database local time, or the application's own configured timezone are all possible — never assume. Modern systems commonly store timestamps in UTC with a trailing Z: 2026-08-30T10:15:32Z. You'll also see explicit offsets: 2026-08-30T10:15:32+00:00 or 2026-08-30T12:15:32+02:00.
Many modern systems use ISO 8601 formatting, e.g. 2026-08-30T14:23:11.827Z: 2026-08-30 is the date, T separates date from time, 14:23:11 is hours/minutes/seconds, .827 is milliseconds, and Z means UTC. Learning to read this format at a glance saves real time once you're pulling logs from five different systems that all format time slightly differently.
2 Milliseconds & Clock Synchronisation
Two events can happen within the same second. Without milliseconds, this entire sequence would appear to happen simultaneously:
10:01:22.101 Request received
10:01:22.154 Database query started
10:01:22.742 Database response received
10:01:22.755 Authentication completedHigh-performance systems sometimes go further, using microseconds or nanoseconds — the finer the granularity, the more reliably you can order events that would otherwise look like ties.
Enterprise systems need synchronised clocks to make any of this meaningful, via NTP, Windows Time Service, Chrony, systemd-timesyncd, or a cloud provider's own time service. Imagine an application server reading 12:00:05 while the database reads 11:59:55 — a ten-second gap that could lead an investigator to wrongly conclude a database event happened before the application even sent the query. Large enterprises synchronise servers to central time sources precisely to prevent this kind of false lead.
3 Time Drift & Daylight Saving Time
Time drift is a system clock slowly becoming inaccurate over time. Consequences include incorrect incident timelines, authentication failures, Kerberos failures (Module 9, Lesson 5 — Kerberos is specifically sensitive to clock differences between systems), certificate validation problems, misleading SIEM correlation, and inaccurate audit trails.
Daylight saving time creates its own trap: a system using local European time can move from 02:59 back to 02:00, meaning two genuinely different events can carry the exact same local timestamp. This is one of the biggest reasons security teams prefer UTC for logging — it never has a "fold back" moment.
4 Unix Epoch Time
Some systems store time as a Unix timestamp — 1788076800 normally represents the number of seconds since 1 January 1970 00:00:00 UTC. Some applications use milliseconds instead: 1788076800000 (note the extra three digits). Learn to recognise both forms on sight, and to convert them, since seeing a bare ten- or thirteen-digit number in a log and not recognising it as a timestamp at all is a genuinely common beginner mistake.
5 Session IDs
Applications commonly assign a unique identifier to a user's session, e.g. session_id=H1B7P9FX29KD. The same value shows up across multiple events:
14:30:10 session=ABC123 LOGIN_SUCCESS
14:30:12 session=ABC123 GET /dashboard
14:31:17 session=ABC123 GET /account
14:32:05 session=ABC123 LOGOUTThis lets you reconstruct one user's activity precisely. Searching only username=alice could pull in multiple separate login sessions mixed together; searching session_id=ABC123 isolates exactly one.
Session identifiers are also security-sensitive — depending on the application, possessing a session cookie or token can let someone impersonate the user (Module 9, Lesson 6's session-hijacking discussion). Logs should never unnecessarily record passwords, full authentication tokens, private keys, complete session cookies, credit card information, or other sensitive personal information. Secure logging is itself a security control, not just an operational nicety.
6 Common Identifiers Worth Searching For
During an investigation, keep an eye out for: username, email address, user ID, session ID, transaction ID, correlation ID, request ID, trace ID, device ID, IP address, hostname, MAC address, process ID, thread ID, container ID, pod name, API client ID, OAuth client ID, and certificate serial number. Finding one identifier in a log line very often lets you pivot straight into a completely different log source that shares it — the whole investigative chain Lesson 1 described depends on having a list like this in mind before you start searching.
Lesson Outcome
You should now be able to explain why a bare timestamp is meaningless without knowing its timezone, read ISO 8601 timestamps confidently, explain why clock synchronisation and daylight saving time both create real investigation traps, recognise Unix epoch timestamps, and use session IDs and other identifiers to pivot between related log sources. Lesson 3 puts all of this to work on the two operating systems you'll investigate constantly: Windows and Linux.