Time on a Phone Is Not Time in the Real World

A forensic extract contains a single row that seems to decide the whole case. Beside a photograph found on the phone is the time 22:17:08. The image shows the entrance to a house, a parked car and, reflected in the glass, part of a person whose presence is disputed. Something happened there a few minutes later. The phone’s owner says he was no longer present.

The photograph’s time looks more objective than testimony. A witness can be mistaken. A suspect can lie. Memory is rewritten. But a phone has no motive. It entered 22:17 in the table, apparently closing off doubt: the photograph was taken at 22:17, the phone was at the location at 22:17, and its owner must therefore have been there too.

Then a more detailed extract of the same file is opened. Beside DateTimeOriginal: 22:17:08 another value appears: File created: 22:43:51. The application database also contains 2026-06-14T20:18:14.622Z. And the cloud history does not record synchronisation until the following day at 03:12:04.

Four values. One file. Which time is “correct”?

The most convenient answer is that one of them must be wrong. The more precise answer is less comfortable: all of them may be true. Each may simply describe a different technical event. And none, on its own, necessarily proves exactly what we have decided to read from it.

A Time Needs a Verb

“22:17” by itself is not a claim about the past. It is a value. It acquires meaning only when we attach a verb: the photograph was taken, the message was sent, the file was created, the data were received, the backup was restored. That verb is precisely where a technical value quietly turns into a story.

A digital system does not usually record “the moment of the real-world event”. It records a change in its own state: the creation of a database item, receipt of a request by a server, storage of a file in a directory, a content change, synchronisation or the display of a value to a user. The specialist literature therefore distinguishes the observed artefact, the technical event it may represent, and the wider event in the physical world that the analyst is trying to reconstruct. A timestamp row in a tool is not itself the event; it is a trace of a change whose meaning must first be established.^[1]

Asking the right question therefore means breaking one simple sentence into five layers: which system recorded which change, by which clock, in which time representation and how the software subsequently displayed it. Only then can we decide which part of the real-world event the value relates to.

One Photograph, at Least Four Events

A photograph is the perfect trap because it looks like a single object. In reality, it may carry several temporal layers created at different moments and in different places.

Inside the file may be the EXIF field DateTimeOriginal, intended to indicate when the original image data were created. On a digital camera or phone, it will usually derive from the device clock at the moment of capture. But the text itself need not contain a time-zone value; the standard defines separate offset fields, which may be absent. EXIF can be stripped during export, changed during editing or never created at all. Its precise meaning and survival therefore depend on the device, format, application and version.^[10]

Alongside it are file-system times. Creation time typically says when this particular file object was created in this particular storage location. If a photograph is downloaded from the cloud, received through a messenger, restored from backup or copied to a new device, it may be “created” long after it was taken. Modification time may indicate the last write to the content or another change under the rules of the particular system. Access time need not be the exact moment a person viewed the image either: some systems defer or restrict updates, or operate at coarser resolution. Microsoft, for example, documents that NTFS stores times in UTC while FAT uses local time, and that last-access updates may be delayed.^[6]

Then comes the application layer. A gallery may create a thumbnail, a media index may add the file to a catalogue, a messaging app may record receipt of an attachment, and a cloud service may log an upload or synchronisation. Each operation can create its own timestamp. These are not four versions of the same time. They are the times of four different events converging on one piece of content.

If an analyst inferred the time a photograph was taken from the file-creation time, they would not necessarily be using a forged value. They could be using a perfectly authentic timestamp—and merely attaching the wrong verb to it.

Who Was Wearing the Watch?

Communication times are more complicated still. A message may have a creation time on the client device, a queue time, sending time, server-receipt time, delivery time to the recipient’s account, download time to the recipient’s phone and later synchronisation time. Yet the ordinary interface may show a single number and one vague word: “sent”.

The distinction is not academic. The phone may have no signal. The user presses a button at 22:17, but the application does not transmit the content until 22:26. The server time then reliably establishes when the server received the data, not necessarily when the user made the gesture. Conversely, client time may be closer to the human action, but it depends on the device clock. That clock may be set automatically by the network, shifted manually, temporarily out of synchronisation or changed during travel between time zones.

Client-device time is derived from the clock of the phone or computer on which the user action or local write occurred. Server time comes from a remote system’s clock and usually describes when the server received, processed or stored a request. A server value is often better synchronised and harder for the phone’s user to influence, but that does not automatically make it the time of the human action. A client value may be closer to that action, but it carries the state of the device clock.

Current SWGDE guidance for mobile-forensic analysis explicitly warns that a phone’s date and time may come from the mobile network or manual settings, may differ from the actual time or zone, and that any identified discrepancy must be recorded in the analysis. The same guidance notes that exact artefacts and their functions depend on hardware, operating system, firmware, application, version and configuration.^[4]

Network time synchronisation greatly reduces this uncertainty, but does not erase it. NTP is not a stamp of absolute truth; it estimates clock offset relative to time sources and also works with delay, dispersion and expected error. Depending on the implementation, a system may correct its clock gradually or in a step. For analysis, it therefore matters not only whether the device “used automatic time”, but whether records exist of synchronisation, time-zone changes or clock corrections during the relevant period.^[9]

UTC Is Not the Place Where the Event Happened

Time zone is another layer lost in ordinary reading. The notation 2026-06-14T20:18:14Z identifies an instant in UTC. In Prague during daylight-saving time, that same instant is displayed as 22:18:14. These are not two different events or a two-hour error. They are two representations of the same instant.

A Unix timestamp goes further still: it usually stores the number of seconds since the epoch of 1 January 1970 in UTC. The value 1781468294 contains neither “Prague time” nor information about where the phone was. Only software translates it into a date and time for the selected zone. Some systems also use milliseconds, microseconds or other epochs. Confusing seconds with milliseconds does not create a one-hour shift; it may produce a date that looks absurd—and still be nothing more than a misinterpreted unit.

There is also a difference between a UTC offset and time zone. The value +02:00 states the relationship to UTC at a particular instant. The designation Europe/Prague carries a set of rules under which the offset changes through history and during transitions between standard and daylight-saving time. Modern internet standards therefore distinguish a fixed timestamp with a UTC offset from supplementary information about a named time zone.^[8]

When clocks go back in autumn, the same local time can occur twice. “02:30” without a date, zone and offset may therefore not identify a unique instant. During the spring transition, by contrast, some local times never occur. And if software applies today’s zone rules to an older local value, its result may differ from that of software using historical rules or only a fixed offset.

That is why the stored value must be distinguished from its display. Two tools can show 20:18 and 22:18 from the same bytes without changing either timestamp. The conversion created the difference.

The Cloud Gives Data a Second Life

A phone ceased to be a closed box long ago. A photograph may be created on one device, sent through a server, automatically stored in the cloud, downloaded to a laptop, edited, synchronised again and eventually restored to a new phone. Each stage generates legitimate time traces.

A cloud service may record creation of an object in its storage, the last change to the cloud copy, upload, thumbnail generation, sharing, download or synchronisation. What its interface calls “created” need not be the moment the original content came into being. SWGDE guidance warns that a cloud object’s creation time may correspond to a download or move, modification time may reflect synchronisation rather than a user edit, and the time zone of a record may not be immediately apparent.^[5]

Migration and restoration from backup create a special temporal illusion. A new phone may contain a three-year-old message even though the database file was created on the device yesterday. An image may retain its original EXIF while its file-creation time records the restoration. An application may import old application timestamps into a newly created database. None of these values need be defective. Each simply follows a different continuity: content, database record, file or device.

Changing devices therefore reverses the usual intuition. A finding “on the phone” need not mean that the data originated on that phone. It may prove that they were synchronised, imported or restored to it. And the absence of an old file time need not mean that the content did not exist earlier; that metadata may have been lost when copying between systems that preserve different kinds of metadata.

The cloud is not merely a source of confusion. It often provides a more independently maintained server time, version history or records no longer present on the local device. But its strength emerges only when the analyst knows which process a field describes and whether the sources being compared are genuinely independent. Three values derived from one cloud event do not automatically constitute three independent confirmations.

A Database Does Not Store “Time”. It Stores an Agreement About Time

A timestamp can look most convincing inside a database: a long number with milliseconds appears scientific. But a database often does not know what the number means. It knows only that a particular column contains an integer, a decimal value or text.

SQLite, widely used in mobile and desktop applications, has no dedicated date/time data type. Time values can be stored as ISO 8601 text, a Julian day number or a Unix timestamp. Meaning is supplied by the application schema and the code that writes and reads the value.^[7] A column named created_at may contain seconds since 1970, milliseconds since the same epoch, local text without a zone or server time. The field name is a clue, not proof of its exact semantics.

The more important question is who created the value. Did the client write it from the phone clock? Did the server add it when receiving the request? Was it copied from an imported record? Did synchronisation update it? A database may simultaneously store the content-creation time, the record’s last-modified time and the last-sync time. If all three columns are placed on one timeline without understanding their meaning, the result is beautifully ordered—and factually false.

That is why expert interpretation requires documentation and verification on a comparable system. Exact behaviour may change between application versions. An update can move time from client to server, change the unit or introduce a new field. Where documentation is absent, uncertainty is a legitimate conclusion—not confident assignment of the most likely meaning.

When a Tool Translates Time

Software usually stands between the raw artefact and the human observer. A forensic tool reads bytes, recognises a format, decides whether a number represents seconds or milliseconds, assigns an epoch, converts it to UTC or a configured zone and adds a label. Every step may be correct—and every step adds interpretation.

That is why a graphical interface may display local time while a CSV export contains UTC. One analyst may configure the project for the evidence device’s zone, another for their own local time. An older parser version may label the same field differently from a newer one. And some software may convert zone-less local text according to the computer’s settings even though the device was elsewhere when the event occurred.

Sound temporal analysis therefore preserves three forms of the value: the raw value, the decoded meaning and the displayed value in a stated time zone. It also records the tool version, project settings and extraction method. Not because tools cannot be trusted, but because they are translators. After reviewing the scientific foundations of digital investigation, NIST concludes that the techniques in use derive from established computer-science methods and are considered reliable when properly applied.^[3] The words “when properly applied” matter more here than the software brand.

Authenticity, clock accuracy and evidential meaning are three different questions. A value may be authentically stored in the original database but come from a wrongly set clock. It may be temporally precise but mark server receipt rather than image capture. And it may correctly prove a data transfer without proving who was holding the phone.

Strength Emerges at the Intersection

Return to the photograph from the opening. EXIF gives 22:17:08 but contains no certain time-zone information. The server records receipt at 20:18:14.622 UTC, or 22:18:14 local daylight-saving time. A network trace shows transmission between 22:18:12 and 22:18:16. The recipient’s phone stores the file at 22:43:51, and the cloud synchronises it overnight.

Those data do not justify saying that the shutter was pressed at exactly 22:17:08. But they support another statement: if it is established that the server received this exact content, the content must have existed no later than 22:18:14. The network trace supports the same sequence. EXIF is consistent with capture roughly a minute before transmission, but its weight depends on the accuracy of the device clock and the integrity of the metadata. The file-creation time of 22:43 does not describe capture; it fits the later storage of a copy.

A sound timeline is therefore not produced by mechanically sorting every timestamp. It is produced by assigning each value an origin, clock, format, possible offset and technical event. Only then do we look for matching sequences, contradictions and temporal anchors: server logs, synchronisation records, network events, data from another device or other traces whose relationship to external time is better known.

The result need not be a point. Often it is an interval and an order: the content already existed; then it was transmitted; later it appeared on this phone; finally it was synchronised. That conclusion may be less dramatic than a bold “22:17”, but it is usually far more precise.