Time zone and clock errors

A timestamp can be decoded perfectly and still be wrong: stored in local time and reported as UTC, converted with today's rules instead of those in force on the day, shifted by the analyst's tool, or recorded by a clock that was minutes or years off. This lesson shows which sources store UTC and which store local time, how to convert local values, and how to measure, document and correct a device clock error. Module 7 covers deliberate clock tampering; here the goal is to get honest timestamps right.

Three clocks in every case

Keep three clocks apart in your notes:

1. True time (UTC): when the event really happened. This is what your report must state.
2. The device's system clock: what the computer believed the time was. Artifacts record this clock, never true time. If it was 7 minutes fast, every timestamp it wrote is 7 minutes late.
3. The display clock: how a tool shows a value on the analyst's workstation. Event Viewer, for example, shows UTC-stored EVTX times in the viewing computer's zone.

Errors come from mixing them up.

UTC sources and local-time sources

Two formats sit in between. exFAT stores local time plus a per-timestamp UTC offset byte, which is usable only when its valid bit is set (Lesson 1.5). EXIF 2.31 and later can add OffsetTimeOriginal, such as -03:00. A text log that writes an offset, such as Apache's [14/Mar/2026:09:21:07 -0300], is also unambiguous. Without such a marker, assume local time and find out whose local time: the host's, or that of a camera that was never set.

The hardware real-time clock (RTC) adds a trap: Windows keeps it in local time by default, most Linux distributions in UTC, so a dual-boot machine can be off by the zone's offset until resynchronized.

Converting local time to UTC

Windows stores offsets as a bias in minutes, with the opposite sign to the usual "UTC−3" notation: bias = −(UTC offset), and UTC = local time + bias. UTC−3 has a bias of +180; UTC+1 has −60. During daylight saving time (DST) the bias in effect is Bias + DaylightBias (usually −60), so Central European Summer Time is −60 + (−60) = −120. Lesson 2.2 shows where these values live under TimeZoneInformation.

Missing and repeated hours

At a DST transition, local time jumps. In Central Europe on 2026-03-29, clocks went from 01:59:59 CET to 03:00:00 CEST, so local times from 02:00 to 02:59 do not exist that day. On 2026-10-25 they went from 02:59:59 CEST back to 02:00:00 CET, so every local time from 02:00 to 02:59 happened twice, once at UTC+2 and once at UTC+1. A local-time log line at 02:30 that day is ambiguous by one hour. Resolve it from neighboring entries or a UTC source, and say how.

Use the rule in force on the event date

ActiveTimeBias describes the moment the key was last written, not the date of your event. Time zone rules also change by law. Brazil abolished DST in 2019; its last DST period ended on 2019-02-17. A Brasília host collected in 2026 shows ActiveTimeBias 180, but a local log line from 2018-12-10 10:00 was written at UTC−2 and is 12:00Z, not 13:00Z. Convert every value with the rules for its own date, using an up-to-date time zone database (the IANA tz database) or the per-year rules Windows keeps under SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone>\Dynamic DST.

Never let a tool pick your time zone

Many tools silently apply the analyst workstation's zone:

• Set the analysis workstation to UTC, so a fallback to "local" is harmless.
• In Plaso, state the output zone explicitly: psort.py --output_time_zone UTC. When local-time sources such as FAT volumes are parsed, pass the device's zone with log2timeline.py --timezone (Lesson 3.3).
• In GUI tools, check the display settings. Autopsy's view options choose the time zone used for display. Timeline Explorer shows the timestamps of the CSV it opens, so produce that CSV in UTC and set its date format to show seconds and fractions. Then confirm one row against a hand-decoded value.
• Spreadsheets are dangerous. Excel converts date-like text into serial numbers that carry no time zone, hides seconds and fractions in its default display format, and can read day and month the other way round under some regional settings. Import timestamp columns as text.

Clock skew and drift

Skew is the offset between the device clock and true time at a given moment. Drift is how fast that offset changes. A free-running quartz clock with an error of 20 parts per million gains or loses about 1.7 seconds a day (20 × 10⁻⁶ × 86,400 s), so an unsynchronized device can be minutes off after a few months. Synchronization corrects the clock by slewing (running it slightly faster or slower until it agrees) or by stepping it at once. Only steps leave a "time changed" record.

Measuring the offset

Compare the device clock with a reference you trust:

• NTP synchronization records. Events from the provider Microsoft-Windows-Time-Service in the System log show synchronization: event 35 names the time source the service is synchronizing with, and event 37 says that the NtpClient provider is receiving valid time data. They show that synchronization was working, not the size of a correction.
• Kernel-General event 1 (provider Microsoft-Windows-Kernel-General, System log) records a system time change with OldTime and NewTime, both in UTC. The difference is the size of the step.
• Security event 4616, "The system time was changed", is logged when the Security State Change audit subcategory is enabled. It adds PreviousTime, NewTime, the account and the process. Routine corrections by the Windows Time service usually show the LOCAL SERVICE account; a change through a user's process deserves attention.
• Server-side timestamps written by a synchronized clock about the same action: the Received: headers that mail servers add, a web server's access log, or the HTTP Date: response header kept in a browser cache entry. A server's Last-Modified: header gives a lower bound: a download cannot be created locally before the content was last changed on the server.
• At collection, record the device clock beside a trusted reference. That measures the skew at collection, not necessarily earlier.

Documenting and applying a correction

Write down the reference, how you derived the offset, the interval to which it applies, and the remaining uncertainty. Apply the correction only between known clock events: an offset measured after a step does not apply before it. Keep the original value in your report beside the corrected one.

Out-of-order events

A step backward makes a range of clock readings occur twice, so sorting by time interleaves unrelated events; a step forward leaves a gap. After an RTC battery failure or firmware (BIOS/CMOS) reset, the clock can restart from a firmware default date, producing events "in 2001" or another early year until it is set again; a clock set too far ahead creates files "in the future". Such patterns are normal consequences of hardware and manual changes, not proof of tampering. Look for the Kernel-General 1 or 4616 event that explains them, and restore the true order with sequence numbers that do not depend on the clock: EVTX EventRecordID, USN journal update sequence numbers, $LogFile sequence numbers.

Collection times are not evidence times

Times produced by the collection itself, such as the file system times of copied files in a triage folder and the acquisition time, describe your work, not the user's (Lesson 3.3). Exclude them from the event timeline and use the collection log to measure skew and document custody.

Precision and matching

A DOS value marks a two-second step. Depending on the writer, the true time was truncated to the even second below or rounded up to the one above, so it may lie up to 2 seconds either side of the stored value. When you compare a DOS value with a FILETIME, allow that window; a 1-second difference is not two events. The CFX practical exam accepts a timestamp answer within ±1 second, written in UTC with Z, such as 2026-03-16T09:20:14Z. Report the value of the artifact the task names, converted exactly, and do not round it toward another source.

Worked example 1: a FAT32 file and the host's $MFT

A FAT32 USB image holds plan.docx (short name PLAN~1.DOC). In its directory entry, the time word at offset 0x16 is 87 32 and the date word at 0x18 is 70 5C:

• Time 0x3287: hour = 0x3287 >> 11 = 6; minute = (0x3287 >> 5) & 0x3F = 20; seconds = (0x3287 & 0x1F) × 2 = 7 × 2 = 14, so 06:20:14.
• Date 0x5C70: year = (0x5C70 >> 9) + 1980 = 46 + 1980 = 2026; month = (0x5C70 >> 5) & 0x0F = 3; day = 0x5C70 & 0x1F = 16, so 2026-03-16.

The host's TimeZoneKeyName is E. South America Standard Time and ActiveTimeBias is 180. Brazil had no DST in 2026, so 180 applies on that date: 06:20:14 + 180 minutes = 2026-03-16T09:20:14Z.

The host's $MFT has C:\Users\ana\Desktop\plan.docx with a $SI modification time of 2026-03-16T09:20:12.7Z. The difference is 1.3 seconds, less than the 2-second DOS resolution, so the values are consistent with one modification: a copy keeps the file's modification time, and Windows rounds it up to the next even second on FAT. Reported from the USB drive, the answer is 2026-03-16T09:20:14Z.

Worked example 2: a clock 7 minutes fast

On another host, the System log contains Kernel-General event 1 with OldTime 2026-03-18T13:47:31.5Z and NewTime 2026-03-18T13:40:31.5Z. The step is 13:47:31.5 − 13:40:31.5 = −7 min 00 s: the clock was 7 minutes fast before 13:47:31.5 device time. No earlier time change appears since boot, so the offset applies to the whole morning.

Corroborate with an independent clock: the browser cache entry for the download stores the server's Date: header, 13:22:03Z. Device time 13:29:05 − 13:22:03 = 7 min 02 s, consistent with a 7-minute offset plus 2 seconds of transfer. Document the event's record ID, the offset, its interval and both values for each row.

Exam focus: Expect to convert local-time artifacts such as FAT timestamps, setupapi.dev.log lines or EXIF dates to UTC with the bias and the rules in force on the event date. Be ready to read OldTime and NewTime from Kernel-General event 1 or event 4616 and correct earlier timestamps by the step. Matching questions may pair a 2-second DOS value with a FILETIME; a difference under 2 seconds is not a different event.

Key points

• Separate true UTC, the device clock and your tool's display; artifacts record only the device clock.
• FILETIME, Unix and APFS times are UTC; FAT/DOS, many text logs, some SYSTEMTIME values and EXIF DateTimeOriginal are local; exFAT may carry a valid UTC offset.
• UTC = local + bias, with bias = −(UTC offset) and the DST and legal rules of the event's date, not today's ActiveTimeBias.
• Force UTC in every tool and keep spreadsheets from reinterpreting timestamps.
• Measure skew against trusted references (Kernel-General 1, 4616, server headers, collection notes) and apply corrections only within the interval they cover.
• Account for resolution: DOS modified times are 2-second values, and the exam accepts ±1 s in UTC with Z.