Message timestamps and time zones explained

A timestamp needs an instant, a zone, and a meaning

“10:15” alone is not a complete timestamp. It may be the phone’s local time, a server instant rendered in the viewer’s current zone, or text that lost its original offset during export. A careful record preserves the raw value, states the display zone, and explains what event the field represents.

Store UTC where the source supplies enough information to derive it. Also retain the source text, offset, precision, and sequence. Never overwrite an original field with a normalized value.

Formats differ by platform

The practical differences are easier to compare side by side:

Source	What a typical record shows	Zone information	Preserve
Messages on iPhone	Device-rendered dates and times; exact display depends on the view	Not necessarily visible in a screenshot	Original capture, device zone, date separators, source order
WhatsApp text export	Locale-formatted date and local-looking time	No zone or offset in each line	Raw text, locale, exporting device zone if known
Telegram Desktop JSON	date plus date_unixtime in documented export structures	Unix value gives an absolute reference	Both fields and export order
Meta message JSON	timestamp_ms in documented message data structures	Numeric epoch-style value	Unchanged integer and source package
Discord API data	ISO 8601 timestamp strings with an offset	Offset is included in the timestamp	Exact string, message ID, and sequence

Messages on iPhone. The Messages interface shows dates and times using device settings. Treat a screen capture as a displayed device time unless the underlying source supplies more. Record the phone’s zone at capture and any known travel or manual clock change.

WhatsApp. A plain-text chat export contains locale-formatted date and time lines but no time-zone name or UTC offset. A line such as 29/09/2026, 10:15 therefore cannot establish UTC by itself. Preserve the locale and record the exporting phone’s time zone separately.

Telegram. Telegram Desktop’s JSON export structures include date and date_unixtime. Preserve both. The Unix value supports an absolute instant; the readable date is useful for checking how the export rendered it.

Meta. Meta message JSON commonly represents message time as timestamp_ms. Treat it as a millisecond timestamp and preserve the integer. Convert only in a derived display column, with the target zone named.

Discord. Discord’s developer reference uses ISO 8601 timestamp strings, which can include an offset, and documents that snowflake IDs encode milliseconds since Discord’s epoch. Preserve the explicit timestamp field. Do not infer a message time from an ID when the source already provides a timestamp.

Daylight saving time creates real ambiguities

When clocks move forward, some local times never occur. When clocks move back, an hour repeats. In New York, for example, 2026-11-01 01:30 can refer to the first 1:30 or the second. The UTC offsets distinguish them; the bare local clock does not.

Source value	Display interpretation	What to record
2026-11-01T05:30:00Z	1:30 a.m. EDT in New York	UTC, America/New_York, UTC-04:00
2026-11-01T06:30:00Z	1:30 a.m. EST in New York	UTC, America/New_York, UTC-05:00
11/1/26, 1:30 AM	Either occurrence is possible	Raw text, source order, zone unknown or asserted separately
2026-09-29T10:15:00+01:00	9:15 a.m. UTC	Original offset and normalized UTC

If the source lacks an offset, do not silently choose one. Label the ambiguity. Source order can still show which message preceded another even when two clock labels match.

The verified 2026 transitions provide two useful worked examples. In New York, daylight saving time begins on March 8, 2026. Clocks move from 1:59:59 a.m. EST to 3:00:00 a.m. EDT, so a bare local time of 2:30 a.m. did not occur there that day. It ends on November 1, producing the repeated 1 a.m. hour shown above.

In the United Kingdom, clocks go forward on March 29, 2026 and back on October 25, 2026. A London time of 2026-10-25 01:30 occurs twice: once during British Summer Time at UTC+01:00 and once during Greenwich Mean Time at UTC+00:00. If the source has no offset, neither occurrence can be selected from the clock label alone.

Do not use a fixed abbreviation such as “EST” for every New York date or “BST” for every London date. Use an IANA zone such as America/New_York or Europe/London when you are applying zone rules, and preserve the resulting offset for each instant.

Travel changes display without changing the event

A person can send in London and later view the conversation in New York. Some apps render the stored instant using current device settings; exported text may instead preserve the display produced at export. A screenshot made after travel can therefore show a different local clock from an earlier screenshot of the same event.

Record travel only when known. Do not infer a sender’s physical location from an offset. Time-zone settings, virtual devices, and manual clocks can differ from location.

Build a simple travel log only from known information. It can state that the collecting phone was set to Europe/London on one date and America/Los_Angeles on another, with the source for that fact. Do not “correct” messages between those dates merely because a flight was likely. Automatic zone updates can be disabled, delayed, or overridden.

A screenshot should be described as what the device displayed at capture. An export timestamp may instead represent what the export process rendered. Keep the screenshot capture time separate from the message time. They answer different questions.

Sent, delivered, and read are separate events

A sent time describes creation or acceptance for sending, depending on the platform. Delivery means a service or recipient device reported delivery. Read means the platform recorded a read state under its rules. These can differ by seconds, hours, or indefinitely.

Do not turn one field into three labels. If an export records only a message timestamp, call it the source message time. If delivery or read information is available, preserve each value separately and identify its source.

Keep source sequence ahead of clock order

Conversation order should follow the native database order, platform export order, or capture order. Time is a check, not a license to rearrange. Delayed delivery, imports, clock corrections, and DST can produce apparent reversals.

Assign a stable sequence number. If message 104 displays 10:03 and message 105 displays 10:02, keep 104 before 105 and flag the discrepancy. Re-sorting can manufacture a conversation that no participant saw.

Imported and forwarded conversations need the same discipline. A forwarded message may carry a new event time while quoting older content. A restored backup may place records into a database without changing their message times. A server retry can create apparent ties. Record the platform’s supplied order and use time as a field, not as the only key.

Precision matters too. Do not add seconds to a source that showed minutes, or a time to a source that showed only a date. In structured output, use an explicit precision field such as second, minute, or day. In prose, say “time not shown” rather than inventing midnight.

State the export’s display convention

Use one zone throughout a PDF and print it in the cover or footer: “Times shown in America/New_York; UTC offset varies with daylight saving time.” For CSV, include raw value, normalized UTC, local display, zone, offset, and precision where available.

When the source zone is unknown, say so: “WhatsApp export supplied local date and time without a zone. America/Chicago was provided by the exporting user and has not been independently verified.” That sentence is more useful than false certainty.

Write a time-zone statement someone can audit

A good statement identifies the source, conversion, assumptions, and uncertainty. For example:

The source Telegram JSON supplied date_unixtime values. This PDF displays those instants in America/New_York and prints the applicable UTC offset beside each message. Raw values and source order are retained in the accompanying CSV.

For local-only source text, use narrower language:

The WhatsApp text export displays dates and times without a time-zone field. The exporting phone was reported to be set to Europe/London on September 29, 2026. No UTC conversion has been asserted. Messages remain in source order.

If travel crosses the range, divide the statement by documented period or leave the values unconverted. If a repeated hour is ambiguous, identify the affected messages by sequence number. Never bury a zone assumption in a spreadsheet formula.

Validate conversions without overwriting source data

Keep raw and derived fields in separate columns. A practical CSV can include source_timestamp, source_offset, normalized_utc, display_local, display_zone, precision, and conversion_note. Blank is better than a guessed value.

Spot-check dates on both sides of a daylight saving transition and at year boundaries. Confirm that milliseconds were not mistaken for seconds. Check that spreadsheet software did not reinterpret day-first dates as month-first dates. Save structured values as text where automatic conversion would be risky.

Finally, compare a sample back to the native app or original export. A mathematically correct conversion can still use the wrong assumed zone. Record the software and zone-data version used for consequential conversions so the result can be repeated.

Document uncertainty instead of averaging it away

Uncertain timestamps should remain visibly uncertain. If only the day is known, use the day. If the device zone is reported but not independently checked, attribute it to the person who supplied it. If two UTC instants are possible during a repeated hour, list both possibilities or leave UTC blank.

Do not average conflicting clocks or choose the value that best fits the narrative. Put the competing values in a discrepancy note with their sources. The conversation can still be useful when source order, content, and surrounding events are clear. Precision is a property of the source, not a formatting preference.