How should I build a timeline from several applications?¶

title: How should I build a timeline from several applications? subtitle: Normalise times, preserve source labels and distinguish recorded events from analytical inferences. slug: how-should-i-build-a-timeline-from-several-applications series: mobile-extraction-and-reader-reports section: timestamps-and-timelines card_type: question_card content_type: core-operational risk_level: high-risk pathway_order: 49 section_order: 9 status: draft owner: IF Digital last_updated: '2026-07-25' version: '0.1' review_gate: pending review_mode: ai-assisted review_timebox_mins: 60 qa_gate: pending qa_count: 0 pipeline_ref: PIPELINE_PRG_001 pipeline_version: '1.1' public_safe: true video_ready: true word_count: 467 estimated_read_time_seconds: 193 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - timeline - chronology - cross-application - normalisation sources: - title: SWGDE Best Practices for Mobile Device Forensic Analysis url: https://www.swgde.org/documents/published-complete-listing/20-f-005-swgde-best-practices-for-mobile-device-forensic-analysis/ - title: 'NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics' url: https://csrc.nist.gov/pubs/sp/800/101/r1/final - title: 'Apple Support: Schedule or display events in a different time zone in Calendar on iPhone' url: https://support.apple.com/en-gb/guide/iphone/iph69525c028/ios - title: 'Google Calendar Help: Use Google Calendar in different time zones' url: https://support.google.com/calendar/answer/37064?co=GENIE.Platform%3DAndroid&hl=en-GB

How should I build a timeline from several applications?¶

Normalise times, preserve source labels and distinguish recorded events from analytical inferences.

Script¶

A cross-application timeline can reveal sequence, corroboration and gaps.

It can also create false precision if different timestamp types are merged without explanation.

Start with the proposition.

What period and event are you trying to understand?

Don't export every timestamp on the device simply because the tool can.

Select sources that may answer the question.

For each entry, preserve the original information:

application or system;

artefact type;

stored timestamp;

timezone or offset;

reader display time;

event meaning;

source path;

and any known clock issue.

Then choose a common ordering standard.

UTC is usually the clearest shared reference because it avoids local timezone and daylight-saving ambiguity.

Convert local values only where the original zone or offset is known.

Don't force an ambiguous local timestamp into UTC by guessing.

Keep the original local value and mark the uncertainty.

Retain human-readable local time where operationally useful.

A timeline can show both:

13:32 UTC;

14:32 BST.

That helps people understand the local sequence while preserving a universal standard.

Now distinguish event types.

A message creation, provider submission, delivery, read event and notification are not duplicates.

Label them clearly.

A photograph capture and later cloud download are separate events.

A browser visit and cached image creation may belong to one broader activity.

Don't flatten every entry into “user activity”.

Use confidence and source categories.

For example:

direct source timestamp;

converted timestamp with known offset;

inferred time range;

or uncertain field.

Keep analytical conclusions separate from recorded events.

The timeline entry might say:

“14:32: Provider records message delivery.”

Your analysis may add:

“This occurred shortly before the recipient’s reply.”

Don't rewrite the entry as:

“14:32: Suspect completed the fraud.”

That conclusion may rely on several records and should be explained separately.

Check for shared dependencies.

A notification, parsed message and search index may all derive from one underlying application event.

Don't treat them as three independent confirmations.

Conversely, provider, recipient-device and CCTV records may be independent sources that reinforce the sequence.

Document conversion rules.

Record the reader timezone, daylight-saving treatment, device-clock offset and any manual corrections.

Don't silently edit times in a spreadsheet.

Keep a transformation column or note showing how the displayed value was produced.

The common mistake is to make all timestamps look uniform and lose the source distinctions.

Another is to place an uncertain event between two precise events as though they have equal accuracy.

A good timeline has columns for:

normalised time;

original time;

source;

event;

artefact reference;

precision or uncertainty;

and analysis note.

Review anomalies rather than deleting them.

An impossible time may reveal a wrong clock, synchronisation, inherited metadata or parser problem.

A defensible timeline is not just sorted dates.

It is a transparent model of which systems recorded which events and how their times were aligned.

Use one common time standard for ordering, while retaining the original timestamp, source and event meaning for every entry.

Related questions¶

• Is the timestamp stored in UTC or local time?
• Why might an application timestamp differ from the phone timestamp?
• How should I deal with missing or impossible-looking times?

Source notes¶

• SWGDE Best Practices for Mobile Device Forensic Analysis
• NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
• Apple Support: Schedule or display events in a different time zone in Calendar on iPhone
• Google Calendar Help: Use Google Calendar in different time zones