How do you build one UTC timeline from NTFS MACB times, a local-time app log and UTC proxy records?

## The problem, concretely An eleven-week slow-drip of documents left an enterprise through a sanctioned file-sync client, run under the account of an employee who spent the period travelling across three time zones with a company laptop. Four sources describe it, and each expresses time differently: 1. **NTFS MACB values** on the synced folder — stored in UTC, *displayed* in whatever zone the examination tool was told to use. 2. **The sync client's application log** on the laptop — wall-clock local time, no offset written into the line. 3. **The cloud proxy's upload records** — UTC, with the tenant, object name and byte count. 4. **Windows event records** from the same laptop, whose zone was never set during imaging or provisioning. A naive normalisation — pick one offset, add it to everything — produced a timeline in which the exfiltration began the week of the first proxy alert. Resolving the offsets properly moved the start **eight weeks earlier**. ## Step 1: choose one reference and normalise into it UTC, always, and quote it in the report as UTC. Never build a timeline in "local time" — local time is not a single quantity for a roaming host, and it silently changes under you at a daylight-saving boundary. ## Step 2: for each source, answer three questions before you convert anything - **What does this field mean?** A birth time is the file appearing on a volume; a proxy record is the moment the request reached the proxy; an application log line is when the client chose to write the line, which may trail the operation it describes. Ordering fields that measure different things is a category error even when the arithmetic is perfect. - **What is it expressed in, and is that recorded or assumed?** UTC stated in the record, local time with a written offset, and local time with nothing at all are three very different situations. The third is the one that hurts. - **What resolution does it carry?** NTFS is 100-nanosecond; proxy and application logs are usually whole seconds. Two events inside the same second from different sources are not orderable, and pretending otherwise is how a report acquires a claim it cannot defend. ## Step 3: the roaming-laptop trap The sync client's log is the dangerous source. Because the machine's wall clock followed the traveller, its lines are **not** a fixed delta from UTC: three zone changes and a daylight-saving transition mean the correct offset differs by row. Applying a single delta compresses or stretches the whole eleven weeks and can invert the order of events that were hours apart. The offset has to be resolved **per record** from the host's zone history — which is itself an artefact you have to establish, not assume — or empirically, source by source and period by period. ## Step 4: a field that says UTC is not a guarantee of correct UTC Windows event records store their time as UTC computed from the system clock and the configured zone. If the zone was never set, the machine has been converting local wall-clock time to "UTC" with the wrong offset the whole time. The record looks authoritative and is wrong by a constant. The lesson generalises: a record's stated time reference tells you what the *writer believed*, and belief is not verification. ## Step 5: anchor, then verify The fix for both problems is the same. Find an **anchor event** that two independent sources captured — here, one upload that appears in the sync client's local-time log *and* in the proxy's UTC records, matched by object name and byte count so the pairing is not itself a guess. The difference between the two recorded times is the offset for that source in that period, measured rather than assumed. Repeat for each period on either side of a zone or daylight-saving change. Then take a *second*, unused anchor and check that the derived offset predicts it. An offset validated against one pair and confirmed against another is defensible; one derived from arithmetic on a zone name is not. ## Step 6: carry provenance on every row The timeline is not a list of times, it is a table where each row keeps: the source, the original value **exactly as recorded**, the original stated reference, the offset applied, how that offset was derived, the resulting UTC value, and a confidence marker. This is what makes the timeline reviewable — a second examiner can re-derive it — and it is what lets you correct one source later without rebuilding the whole account. Rows whose offset you could not establish stay in the table, flagged as unordered, rather than being quietly assigned a plausible time. ## Step 7: state the result as an interval With all four sources normalised, the earliest defensible upload sat eight weeks before the alert that started the case. Report it as the **earliest activity the evidence supports**, alongside the first independently corroborated event, and say which sources support each. That is a stronger and more honest sentence than a single start date, and it is the sentence that survives being read back to you months later.