Is the timestamp stored in UTC or local time?¶
title: Is the timestamp stored in UTC or local time? subtitle: The report may display local time even when the underlying value is UTC, or display an unconverted local value as though it were universal. slug: is-the-timestamp-stored-in-utc-or-local-time series: mobile-extraction-and-reader-reports section: timestamps-and-timelines card_type: question_card content_type: core-operational risk_level: high-risk pathway_order: 43 section_order: 3 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: 454 estimated_read_time_seconds: 188 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - UTC - local time - timezone - conversion 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: '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
Is the timestamp stored in UTC or local time?¶
The report may display local time even when the underlying value is UTC, or display an unconverted local value as though it were universal.
Script¶
Mobile applications and operating systems don't all store time in the same way.
Some store a universal value such as UTC.
Some store local wall-clock time.
Some store UTC together with an offset.
Some use an application-specific epoch or numeric format.
The forensic tool may then convert the value into a readable date and time.
That means the time shown in the report may not be the value stored in the source.
Start with the field definition where available.
Does the parser identify the value as UTC, local, server time, device time or converted time?
Does the report show an offset such as +01:00?
Does it label the display timezone?
Can the details panel expose the raw numeric value?
If the artefact is important, ask the examiner how the parser treats the field.
UTC is useful because it creates a common reference independent of local timezone and daylight-saving changes.
Google Calendar, for example, explains that events are converted into UTC while users normally see them in local time.
Applications may follow a similar model.
But not every record does.
A local timestamp without an offset is ambiguous.
“10:00” could mean 10:00 in London, New York or another zone.
If the device travelled, the same displayed value may represent different universal times.
The reader’s settings also matter.
A reviewer may choose to display every artefact in UTC, the device timezone, the examiner’s timezone or another selected zone.
Two reviewers can therefore open the same extraction and see different clock times for the same stored event.
That does not mean the source changed.
Daylight saving creates another issue.
London is UTC in winter and UTC plus one hour during British Summer Time.
A conversion should use the offset that applied on the event date, not the offset applying when the report is reviewed.
Timezone rules can also change historically.
Keep the original value and conversion basis.
For a significant timestamp, record:
the raw or stored value if available;
the source field;
the original offset or timezone;
the timezone selected in the reader;
and the converted display value.
The common mistake is:
“The report is set to UK time, so every timestamp was created in UK local time.”
The viewer may simply be converting universal values for convenience.
Another mistake is to convert a local wall-clock value again as though it were UTC, creating an hour or more of error.
A careful note might say:
“The source stores 2026-07-25 13:32:18 UTC. The report displays 14:32:18 Europe/London because British Summer Time applied.”
Where the source basis is uncertain, say so.
Time conversion should be transparent, repeatable and reversible.
Don't let a friendly display hide the underlying time standard.
Key takeaway
Record both the stored value and the display conversion where time is important.
Related questions¶
- Which timestamp in a mobile report should I use?
- What happens when the device timezone changes?
- How should I build a timeline from several applications?
Source notes¶
- SWGDE Best Practices for Mobile Device Forensic Analysis
- 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