Timestamps and time zones

Most forensic conclusions involve time: when a file was created, when a device was connected, which happened first. Timestamps look precise, but each system stores time differently, records different events and may run on a clock that is wrong. This lesson explains what timestamps mean, how they are stored, how time zones and clock errors affect them, and how to combine them into a reliable timeline. Lesson 6.3 shows the artifacts that hold many of these timestamps.

What a timestamp records

File systems commonly record up to four times for each file, often abbreviated MACB:

The exact meaning depends on the file system and the operating system. On Linux, the classic "ctime" means metadata change, not creation; creation time is a separate field that ext4 records. Access times deserve particular caution: Windows can disable last-access updates, and whether they are recorded depends on the version and settings, so an access time may be old, approximate or never updated.

How systems store time

Computers store time as a count from a fixed starting point, called an epoch. Different systems use different epochs and units.

The practical lesson is twofold. A timestamp means nothing until its format is known, so tools must decode it correctly. And FAT stores local time with no time zone, so the examiner must find out which time zone the device that wrote it was using.

Two sets of NTFS timestamps

Each NTFS file has two sets of four timestamps. The set in $STANDARD_INFORMATION is the one Windows Explorer displays, and programs can change it through ordinary system functions; tools that alter timestamps on purpose, known as timestomping tools, usually change this set. The set in $FILE_NAME is maintained by the file system itself and is updated in fewer situations, such as when a file is created, renamed or moved. A $STANDARD_INFORMATION creation time much earlier than the $FILE_NAME creation time can be a sign of manipulation, but normal operations can also make the two sets differ. Such differences are a reason to look further, not a conclusion on their own.

Time zones and daylight saving time

UTC (Coordinated Universal Time) is the global reference. Local time is UTC plus or minus an offset, which can change during the year when daylight saving time begins or ends. Windows records its configured time zone in the registry, under SYSTEM\CurrentControlSet\Control\TimeZoneInformation, and other systems keep similar settings.

• Find out which time zone each device was set to, and whether that changed over time.
• Know whether each source stores UTC or local time, and how your tool displays it.
• Watch daylight saving transitions: one local hour is skipped in spring, and one occurs twice in autumn.
• Report times in UTC with the offset shown, for example 2026-03-14T12:47:05Z, or the local time with its offset, 2026-03-14T09:47:05-03:00.

Clocks that are wrong

Timestamps are only as accurate as the clock that produced them. A computer that does not synchronize with a time server can drift by seconds or minutes, and a clock can be set wrong by mistake or on purpose. Good practice is to record, at acquisition, the device's clock reading next to a reliable reference time, and to note the difference, called clock skew or offset. If a laptop's clock is 4 minutes fast, its timestamps are adjusted by 4 minutes when compared with a server's logs, and the report explains the adjustment. The offset at acquisition does not prove what the offset was months earlier, which is another limitation to state.

Copying, moving and other surprises

Normal operations produce timestamp patterns that can mislead an unwary examiner. Copying a file in Windows typically gives the copy a new creation time while keeping the original modification time, so the copy appears to have been modified before it was created. Moving a file within the same volume generally keeps its timestamps. Extracting files from a ZIP archive, downloading them or synchronizing them from the cloud can set times in ways that depend on the program used. When a timestamp seems impossible, the first hypothesis should be an ordinary operation, tested before any conclusion about tampering.

Building a timeline

A timeline places events from many sources in one sequence: file system timestamps, registry entries, event logs, browser history, phone records, server logs. Free tools such as Plaso (log2timeline) can extract and merge timestamps from many artifacts. To build one that holds up:

1. Convert every time to UTC, correcting for known clock offsets.
2. Keep the source of each event and its resolution next to it, since a 2-second FAT time and a nanosecond ext4 time are not equally precise.
3. Look for corroboration: an event recorded by two independent sources is far stronger than one recorded by a single timestamp.

A worked example

A company says a confidential file was copied to a USB drive on 14 March. The laptop's NTFS timestamps are in UTC; the USB drive is FAT32 and stores local time; the laptop was set to UTC−03:00. The copy on the USB drive shows 09:47:04 local time, which is 12:47:04 UTC. The laptop's records of the USB device and of the file being opened show 12:47:05 UTC. The one-second difference is consistent with FAT's 2-second resolution. The examiner reports the events in UTC, explains the conversion and the resolution, and treats the match between the two independent sources as corroboration.

Exam focus: Know MACB and that meanings differ by file system (Linux ctime is metadata change, not creation), why access times are unreliable, and the main storage formats: NTFS FILETIME (100-nanosecond intervals since 1601, UTC), FAT local time with 2-second resolution, Unix seconds since 1970. Know the two NTFS timestamp sets and what timestomping changes. Expect scenarios on converting local time to UTC, daylight saving time, clock skew at acquisition, copy-versus-move patterns and corroborating times across sources.