How should I deal with missing or impossible-looking times?¶
title: How should I deal with missing or impossible-looking times? subtitle: Preserve the anomaly, test the source and use ranges or relative ordering rather than inventing a precise correction. slug: how-should-i-deal-with-missing-or-impossible-looking-times series: mobile-extraction-and-reader-reports section: timestamps-and-timelines card_type: question_card content_type: core-operational risk_level: high-risk pathway_order: 50 section_order: 10 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: 491 estimated_read_time_seconds: 203 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - mobile evidence - timestamp anomaly - missing time - impossible time - timeline 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: 'NIST Computer Forensics Tool Testing: Mobile Devices' url: https://www.nist.gov/itl/csd/secure-systems-and-applications/computer-forensics-tool-testing-program-cftt/cftt-7
How should I deal with missing or impossible-looking times?¶
Preserve the anomaly, test the source and use ranges or relative ordering rather than inventing a precise correction.
Script¶
A mobile report may show a blank time, a date in 1970, a future date, an event before the device existed or a sequence that appears impossible.
Don't silently correct or delete it.
Preserve the original value and investigate why it appears that way.
A missing time may mean the source field was empty.
The parser may not support the value.
The recovered fragment may have lost part of the record.
The report may hide the field.
The event may not have a timestamp by design.
A default date such as 1 January 1970 often appears when a Unix-style timestamp is zero, missing or incorrectly interpreted.
Other systems use different default epochs.
A future or extremely old date may result from:
wrong device time;
wrong timezone conversion;
the wrong epoch;
milliseconds interpreted as seconds or the reverse;
signed and unsigned number errors;
corrupt data;
placeholder values;
or application bugs.
An impossible sequence may still describe different event stages.
A file modification before handset import could reflect inherited metadata.
A delivery time before a displayed creation time may result from device clock error or timezone mismatch.
A cloud download may occur after a message was deleted from the original device.
Start with the raw source.
Which field produced the timestamp?
What numeric value was stored?
Which epoch and units does the parser use?
Was the record active or recovered?
Can another tool interpret it?
Does the application version match the parser?
This is an appropriate question for the digital-forensics unit where the anomaly matters.
Compare related records.
A provider event, notification, neighbouring database row, file sequence or another participant’s device may establish relative order or a reliable range.
Even where the exact timestamp can't be repaired, you may be able to say:
the event occurred after account login;
before the next synchronisation;
or between two provider-recorded messages.
Use that range rather than inventing a clock time.
Record any correction explicitly.
If the examiner establishes that a field was stored in milliseconds but parsed as seconds, document the method and preserve the original value.
If the device clock was consistently ten minutes fast during the period, explain which records use that clock and how the adjusted time was calculated.
Don't apply one correction to every timestamp unless their sources justify it.
The common mistake is:
“That date is obviously wrong, so I changed it in the timeline.”
The change may conceal an important source or processing problem.
Another mistake is to discard every anomalous record.
The content and relative position may still be useful even when the absolute time is uncertain.
A careful timeline entry might say:
“Original stored value converts to 1 January 1970 and is treated as missing. Related records place the event between 14:10 and 14:16 UTC.”
That is honest and operationally useful.
An impossible-looking time is evidence about the record and system.
Preserve it, explain it and reduce precision where the source can't support more.
Key takeaway
An anomalous timestamp is a question to investigate, not a value to silently fix or discard.
Related questions¶
- Can the device clock be wrong?
- Why might an application timestamp differ from the phone timestamp?
- How should I build a timeline from several applications?
Source notes¶
- SWGDE Best Practices for Mobile Device Forensic Analysis
- NIST SP 800-101 Rev. 1: Guidelines on Mobile Device Forensics
- NIST Computer Forensics Tool Testing: Mobile Devices