Why Email Dates Change After a Conversion

Email dates change after a conversion because one message carries at least three of them and they do not agree. The sender wrote one. Every server that handled it added another. The mailbox noted when it arrived. Which of them you see is a choice your mail program made without telling you.

That is why dates appear to change during a migration. Nothing was corrupted. A different program made a different choice. A date that was always there became the one on display.

Three Email Dates in One Message

Open a raw message and the dates are all visible at once. They are simply in places nobody looks.

Date: Tue, 12 Jun 2026 14:08:00 +0000
      what the sender's machine believed

Received: by mx.example.net;
  Tue, 12 Jun 2026 14:08:07 +0000
      when a server actually handled it

INTERNALDATE 04-Mar-2026 10:41:12 +0100
      when your mailbox filed it, in its own offset

Seven seconds and one hour separate those three. The seconds are real delay. The hour is the same instant written from a different position.

The first one is the one nobody should trust alone. It comes from the sending machine and it is typed like any other header, so a wrong clock or a deliberate change both produce dates that look perfectly ordinary. The server lines are the ones that carry weight, for the same reason they do everywhere else.

Why the Same Moment Becomes a Different Date

Underneath the readable dates, systems store time as a count. What they count from is not agreed.

None of these is wrong and none can be read as another without converting. A Windows timestamp handed to something expecting Unix seconds gives a date thousands of years out, which at least announces itself.

The dangerous mistakes are the small ones. Dates four hundred years away are obviously broken and somebody fixes it. Dates one hour out look entirely plausible, gets accepted and turns up later in a report where the hour mattered.

Where the Hour Goes in a Time Zone Shift

Most date complaints after a migration are the same complaint. It is not really about dates either.

09:41:00 +0000

two pieces
  the time
  where it was written
  from

09:41:00

one piece
  the offset is gone
  the reader assumes
  its own

Daylight saving makes it look inconsistent. Half the mailbox is an hour out and the other half is correct, which reads like random corruption. It is not. The split falls exactly on the date the clocks changed. Checking a message from either side of that boundary confirms it in a minute.

What Each Mail Format Stores for the Date

The formats disagree about which date deserves to be kept, which is what a conversion has to resolve.

The first three keep the headers, so nothing is lost and a later tool can still choose. The last two keep a decision rather than the evidence. That decision cannot be revisited.

This is the argument for converting to a message format rather than a report. An export to a spreadsheet or a printed copy fixes one interpretation of the date forever. Message formats carry all of them, so somebody in five years can still ask a different question.

Reading an Email Date by Hand

Header dates are readable once you know the shape. That shape has not changed since 1982.

Tue, 12 Jun 2026 14:08:00 +0000
---  - --- ---- -------- -----
 |   |  |    |      |      |
 |   |  |    |      |      the offset from UTC
 |   |  |    |      the local clock where it was written
 |   |  |    year
 |   |  month
 |   day of the month
 day name, optional and ignored

+0000  written at UTC
+0530  five and a half hours ahead
-0800  eight hours behind

The offset is the part that matters and the part most often dropped. Add it to the clock time and you have the instant, which is the only version two systems will ever agree on.

No offset does not mean +0000. Software meeting dates with no offset assumes its own, so the same file read in two countries produces two different instants. Dates carrying +0000 are statements. Dates carrying nothing are gaps somebody else will fill in.

Checking Dates After a Migration

1. Decide which date matters first. Sent, received or filed. They are different questions and no tool can guess which one you meant.
2. Pick messages across a clock change. One from each side of the daylight saving boundary. If both survive, the offset is being carried properly.
3. Compare the raw headers, not the display. Two clients showing different times can be reading the same header correctly. The header is the fact and the display is an interpretation.
4. Check the oldest messages you have. Very old mail is where odd reference dates and missing offsets turn up, because it was written by software nobody supports now.
5. Sort by date at both ends and compare the extremes. First and last message. Anything that moved to the wrong end of the list shows up immediately without checking anything in between.

Totals prove almost nothing here. A migration that moved every message and shifted every date by an hour reports a perfect count. Dates need checking by looking at dates.

Where a legal or compliance request turns on when something was sent, the header is the evidence and a converted display is not. Our file viewers show the raw headers alongside the message, so the dates can be read as they were written. The converters keep the headers intact rather than replacing them with one chosen interpretation.