Timelines, clock changes & timezones
Build a session timeline that preserves original timestamps and distinguishes ordering from exact time.
Question & scope
A timeline should retain the source and meaning of every timestamp. A file modification value, log timestamp, application-generated time, and parser display can represent different events and use different conventions. Record original values and conversion rules before sorting entries into a single session narrative.
Windows Security event 4616 is a useful source for system-time changes; normal clock correction can also produce it. Examine its old/new time and subject context. A change creates a discontinuity to annotate, not a reason to automatically classify every nearby event as deliberate manipulation.
What to collect
| Source | Retain and examine |
|---|---|
| Source timestamp | Original field name, raw value, artifact, and record identifier. |
| Normalization | Timezone, daylight-saving context, units, and parser conversion method. |
| Clock events | Relevant time-change records and available old/new values. |
| Session anchors | Game logs, observed collection times, and independent reference events. |
Examination workflow
- Define the disputed time window and retain its timezone.
- Create separate original and normalized timestamp fields rather than replacing the original values.
- Check artifact semantics and resolution; distinguish intervals from point events.
- Annotate clock changes and investigate whether they affect the apparent order of nearby records.
- Use object and process identities to connect records; do not rely on chronological proximity alone.
Interpretation & false positives
Some sources establish sequence without exact wall-clock time, while others aggregate an interval. Sorting such records by a fabricated precise time can produce a convincing but unsupported story. Prefer a stated interval or sequence constraint when that is all the evidence supports.
A global offset is not automatically valid across a clock discontinuity. Daylight-saving conversion, application-local time, restored files, and archive metadata can all produce differences. Explain unresolved discrepancies instead of silently adjusting timestamps to fit the allegation.
Worked scenario
A download log and a game log appear an hour apart in two viewers. One viewer renders local time and the other UTC. Normalize both using documented rules before describing a contradiction. If a system-time change occurs within the window, preserve separate segments and show which relationships remain uncertain.
Report checklist
- Raw and normalized values are both retained.
- Timestamp meaning and resolution are recorded.
- Clock discontinuities are explicit.
- A timeline does not assign unsupported precision or causation.
Sources & further reading
The workflow and scenario are authored investigation guidance. Confirm source-system and parser support for the build you examine.