Timezones in message exports: why two tools show different times

Two tools can read the same conversation out of the same backup and print different times against the same message, and neither has to be broken. The time you see is a stored instant converted to a clock, and the clock is chosen when the export is made, not when the message was sent.

Where do the timestamps in an iPhone conversation come from?

From a single number per message that counts from a fixed instant and carries no time zone. Two things about that number decide whether a tool reads it correctly, and a third decides which clock the result is printed on.

It counts from 2001, not 1970. Apple’s reference date is 00:00:00 UTC on 1 January 2001, as Apple’s NSDate documentation defines it, and the message database counts from there rather than from the Unix epoch of 1 January 1970. The gap between the two is 978,307,200 seconds, so a tool that confuses them is not slightly wrong. It is about thirty-one years out.

The unit is not always the same. A forensic vendor’s write-up describes the date columns as counting in either seconds or nanoseconds, according to Magnet Forensics, and a tool that assumes one unit is wrong by a factor of a billion on the other. The same article says older iOS versions used the Unix epoch instead. ChatExport 1.0 reads backups from iOS 11 to iOS 26 and counts every value from 2001.

There is no time zone in it. A count from a UTC instant is a moment, not a wall-clock time. To print 14:32, a program has to pick a time zone, and that choice is made by the program and the computer running it, not by the phone.

How can a tool tell seconds from nanoseconds?

By the size of each number. ChatExport treats any value above a trillion as nanoseconds, because a trillion seconds after 2001 would be somewhere around the year 33,700, while a message of any plausible age counted in nanoseconds is far above that line. The decision is taken value by value, so it does not depend on the iOS version and does not care whether one database holds one format or both.

What happens to a message with no usable timestamp?

ChatExport keeps it. A value of zero, a negative value or no number at all is pinned to the start of Apple’s epoch, 1 January 2001, instead of stopping the export with an error. The message stays in the document under a date that is easy to spot.

Which clock does an exported document use?

The clock of the computer that made the export. ChatExport converts every stored instant into that computer’s time zone, with the offset that zone had at that moment, so messages on either side of a daylight saving change each get their own correct offset.

Two consequences:

• Export the same conversation on two computers set to different time zones and the printed times differ. A message close to midnight can land under a different date heading, because the day separators come from the same local time as the times themselves.
• If the conversation happened in one place and the export is made in another, the printed times are the exporting computer’s, not the phone’s.

What should a time in an exported document actually say?

It should say which clock it is on. A bare 14:32 is ambiguous the moment the document leaves the computer that made it.

The PDF title page and the TXT header carry a time zone line naming the zone and every offset that appears among the printed messages, in the form Europe/Warsaw (UTC+01:00/+02:00) for a conversation that crosses a daylight saving change, and a single offset for one that does not. Printing both offsets tells the reader that one offset must not be applied across the whole transcript.

The CSV goes further and writes the full offset on every row, in the form 2026-06-01T23:30:00.000+02:00. That is the file to use when the exact minute across a clock change is the point in dispute. The methodology page on time zones and dates covers time zones and the date order for the whole program.

What if two documents of the same conversation already disagree?

Compare the time zone line on each title page, or the offset in each CSV. If the zones differ, the same instant has been printed on two clocks, and converting one to the other’s offset makes the times agree. If the zones match and the times still differ by decades or by a factor of a billion, one of the tools misread the epoch or the unit.

Why does the English document use AM and PM when the German one does not?

Because the clock belongs to the document language, which is chosen separately from the language of the program’s interface. The English document states times on a twelve-hour clock, as 9:15 AM. The other thirteen document languages use the twenty-four hour clock. The clock applies to every time in the document: message times, delivery and read receipts, captions under photos, deletion markers and the moment the document itself was generated.

Two deliberate exceptions keep the machine-readable parts stable. With full timestamps switched on, the date stays in year-month-day order whatever the language, as in 2026-05-04 9:15:00 AM, and the CSV is the same in every language, raw ISO throughout, because a CSV is a data schema for a script rather than text for a reader.

So two documents of the same conversation, one in English and one in German, show the same moments written two different ways.

Why is a WhatsApp export worse for times than a backup?

Because a backup stores an instant and a WhatsApp export stores only a clock reading. The transcript gives a date and a time on each line and no time zone, so there is no instant to convert, only a wall-clock time to take at face value. ChatExport reads those times in the time zone of the computer running the import, and the import screen says so before anything is exported: “The export file records no time zone, so the clock times are read as this computer time zone.” The title page then names that zone. If the conversation happened somewhere else, the printed times are this computer’s.

How is the date order decided if the file does not say?

Once for the whole file, from the first of these that applies. A transcript can be written day before month or month before day depending on the phone’s settings, and reading 03.04.2026 the wrong way moves every date in the document, so the decision is made across every timestamp at once.

1. A full year written first, as in 2026-04-03, settles it.
2. Any date component above 12, anywhere in the file, settles it.
3. The order of the file itself: an export runs from the oldest message, so if only one reading runs forward in time, that reading wins.
4. If none of the three settles it, day before month is assumed.

The import screen shows the decision and its basis, and in the fourth case it says “assumed, nothing in the file decides it” instead of quietly choosing. The methodology page on time zones and dates holds the same four rules in a table.

For the wider route from a phone to a document somebody else has to accept, the full guide to exporting iPhone messages for court covers what the finished file states about its own source, and what courts require of text messages as evidence covers the question from the decision-maker’s side.