Why Photos Arrive on a New Phone With the Wrong Dates

A photo carries three dates

The rules are written down, publicly, by a standards body. The document is Exchangeable image file format for digital still cameras: Exif Version 2.32, published by the Camera & Imaging Products Association as CIPA DC-X008. It is the reason a photograph taken on one manufacturer’s camera can be read by another manufacturer’s software at all, and it is unusually readable for a specification.

Under the heading “Tags Relating to Date and Time,” it defines three fields. Here is what each one is actually for, in the standard’s own words.

Read that last row twice. The field with the plainest, most inviting name in the whole specification — the one a programmer in a hurry reaches for, the one a spreadsheet column would be called — is defined as the date the file was changed. The standard’s own revision history is even blunter about it, listing the field as “File change date and time.”

All three are stored as plain text in the pattern YYYY:MM:DD HH:MM:SS, twenty bytes including the terminator. And the standard is explicit about the empty case: when a field is left blank, “it is treated as unknown.” That sentence will matter later, because it is the only honest answer to a photograph with no date evidence in it, and it is an answer the specification was willing to write down.

The fourth date, which is not in the photo

Underneath the photograph sits the file, and the file has its own dates that have nothing to do with photography. They belong to the filesystem, and they are a record of what has happened to the file as an object: when it was created here, when it was last written, when it was last read.

Microsoft’s developer documentation defines them precisely. A file time is “a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time,” and — this is the sentence that explains your timeline — “the system records file times when applications create, access, and write to files.”

The system records them. Not the camera. Not the photographer. A file written to your new phone today was, as far as the filesystem is concerned, created today, because that is when it was created there.

The same page is refreshingly candid about how soft these numbers are. “Time stamps are updated at various times and for various reasons,” it says, and “the only guarantee about a file time stamp is that the file time is correctly reflected when the handle that makes the change is closed.” It goes further: “Not all file systems can record creation and last access times, and not all file systems record them in the same manner.” On FAT-formatted media — which is to say a great many memory cards and cheap USB sticks — times are stored in the local time of the computer, while NTFS stores them in UTC. Microsoft’s own worked example is that a file saved at 3:00pm in Washington shows as 6:00pm in New York on one of those filesystems and 3:00pm on the other. Same file. Same bytes. Different answer, depending on the plastic it is sitting on.

Now put the two systems side by side, because Windows does exactly that and most people have never noticed. Microsoft’s property reference defines System.Photo.DateTaken — the “Date taken” column in File Explorer — as “the date when the photo was taken, as read from the camera in the file’s Exchangeable Image File (EXIF) tag,” and lists its property ID as 36867. That is DateTimeOriginal, the good one, by number.

What each kind of move does to the date

There is no single thing called “moving your photos.” There are several mechanically different operations that all feel identical from the sofa, and the differences between them are the whole story. The table below is organized by mechanism rather than by brand, because the mechanism is what decides the outcome — two apps doing the same thing to your files will do the same thing to your dates, whatever their logos look like.

Notice the column that is the same on every row. The filesystem dates are rewritten no matter how careful the route was, because writing a file is, definitionally, creating a file. That is not a bug in anything. It is what the third column of a file listing means.

Notice also how many of the middle cells begin with “depends.” That is not evasion, it is the finding. We went looking for pages where the companies behind these routes state what becomes of a photograph’s capture date, and the honest report is that we could not find one. Apple’s page on moving from Android to an iPhone, for instance, is unusually specific about what transfers — it lists “contacts, message history, SMS messages, camera photos and videos, photo albums, files and folders, accessibility settings, display settings, web bookmarks, mail accounts,” and more besides — and says nothing at all about the metadata inside those photos and videos. That is a statement about the page we read, not an accusation: the category of content is documented, the fate of the metadata is not. We could not find a transfer route that documents it, and we are not going to guess on any of their behalf.

Why a re-encode is a new photograph

This is the mechanism worth understanding properly, because it explains the most complete losses and it is the one people find most surprising.

When software re-encodes an image it does not edit the file you gave it. It decodes that file into raw pixels, throws the container away, and writes a brand new one. Everything that was in the old container — the Exif block, the thumbnail, the color profile, the maker notes, the three dates — exists in the new file only if the code that wrote it went to the trouble of putting it there. There is no law of physics carrying it over. It is a decision somebody made, or did not make, in a function you will never see.

Compression is why so many routes do it. Sending a photograph across a network is cheaper if it is smaller, and the quickest way to make it smaller is to re-encode at a lower quality. The image that arrives is genuinely a photograph of the same scene. It is not the same file, and it never was going to be.

The Exif standard anticipates this, and it is worth noting that it treats editing software as being within scope: the specification explicitly covers “application software that edits Exif/DCF tags and then saves them again or application software that adds metadata information undefined in the Exif Standard in Exif/DCF files and then saves it again,” and devotes a section to the workflow for editing an image with application software. The standard, in other words, knows perfectly well that things will re-save your photograph. It sets out how that should be handled. It cannot make anyone do it.

None of which makes a re-encoding route a bad one. It is the correct engineering choice for sending a picture to a group chat, where nobody wants to wait forty seconds for a photograph they are going to glance at. It becomes a problem only at the moment somebody treats the copy that came out of it as the archive copy — which is exactly what happens when a family library is rebuilt out of the images that friends and relatives have sent over the years.

Why your gallery disagrees with the file

Here is the symptom that sends people looking for an answer, and it is not quite the symptom they think it is.

You open the new phone’s gallery and everything is in a heap, dated this month. You open the same folder on a computer and a lot of the photographs have their real dates back. Nothing has been repaired in between. The two programs simply asked for different fields.

Given the four candidates established above — three inside the file and at least one outside it — “sort by date” is not a single instruction. A gallery can order by the capture date in tag 36867, by tag 306 which means the date the file was changed, by the filesystem’s write time, by the moment the item was added to its own catalog, or by any of these with a fallback chain when its first choice is missing. All of those are defensible designs. They disagree.

There is a second, quieter version of the same problem, and it affects people who think they are being careful. Rename a batch of files, rotate them, run them through a cleanup tool, or let a backup program rewrite them, and the filesystem’s write time moves to the moment you did it. If the software you use to browse the library sorts on that time, an afternoon of tidying will re-order a decade of photographs into the order you tidied them in. The pixels are untouched. The Exif is untouched. The shelf has been reorganized by someone with a different filing system.

This is also why the problem feels seasonal without being seasonal. The mechanism is the same in March. September simply concentrates it, because that is when the handsets ship and everybody performs the move at once.

The missing offset, and the fix that arrived in 2016

There is one more reason a date can be wrong, and it is wrong by hours rather than by years, which makes it harder to spot and more annoying to live with.

Look again at the format the standard specifies: YYYY:MM:DD HH:MM:SS. Twenty bytes of plain text. There is nowhere in that string for a time zone. A photograph taken at twenty past two in the afternoon records “14:20” and no indication of where in the world two o’clock was happening.

That was not an oversight so much as a very long-lived omission. The first edition of the Exif specification was published in October 1995. According to the standard’s own revision history, the offsets did not arrive until Revision 2.31 in July 2016, which “added time difference to UTC (Universal Time Coordinated) as tags relating to Date and Time” — specifically “three time offset tags respectively corresponding to the three existing tags.” One new field for each of the three dates, twenty-one years after the format was first published.

The consequence is straightforward arithmetic. Software that reads “14:20” from an older photograph has to decide what that means, and different programs decide differently: some treat it as local time and leave it alone, others treat it as UTC and shift it into the reader’s zone. Do that to a photograph taken late in the evening and it moves to the following day. This is why a set of holiday pictures can sit one day out from the day you remember, and why the same set can be one day out in one program and correct in another.

A field existing in a standard is not the same as every device filling it in, and the standard is careful on this point too: a blank field “is treated as unknown.” So the fix is real, it is a decade old at most, and it does nothing whatsoever for the twenty-one years of photographs that predate it.

Four things widely repeated that are not true

Each of these is stated confidently in forum threads every September. Each is a misunderstanding of something real.

1. “Date modified is when the photo was taken.” It is not, and the two systems that produce these numbers are documented separately. “Date taken” is defined as being read from the Exif tag numbered 36867; file times are described as recorded by the system “when applications create, access, and write to files.” A file modified today says nothing about when the shutter opened, and a file never modified since 2014 is a coincidence rather than evidence.
2. “Copying photos to a new drive changes their dates.” Half true, and the half that is wrong is the half people act on. A faithful copy cannot alter Exif, because Exif is part of the bytes being copied. What changes is the new file’s own timestamps at the destination — which is unavoidable, since a file has just been created there. If your library looks re-dated after a copy, the capture dates are usually still in the files and something is sorting on the wrong field.
3. “Exif records the time zone, so the time is unambiguous.” Only for recent photographs, and only if the device wrote the field. The offset tags were added in Revision 2.31, July 2016; before that the specification had no field for the time difference to UTC at all. Anything older records a wall-clock time and leaves the interpretation to whoever reads it.
4. “Any decent tool can work out the real date.” Only where evidence survives. If a date is present in the file, or in a companion file, or recoverable from a filename a camera generated, it can be established. If every trace has been re-encoded away, there is nothing left to reason from, and a program that produces a confident date anyway has invented one. The standard has a word for this state, and the word is “unknown.”

What can be recovered, and what cannot

The useful question at the end of all this is not “are my dates wrong” but “is the evidence still in the files.” Those are different questions with different answers, and the second one decides what is possible.

In the best case — and it is much more common than the panic suggests — nothing was ever lost. The capture date sits in tag 36867 exactly where the camera wrote it, the transfer route left the bytes alone, and the only thing that went wrong is that a gallery sorted on the file’s write time instead. Nothing needs recovering. Something needs to read the right field.

In the middle case the capture date is gone from the photo but the evidence has not all gone with it. There may be a second Exif date still present, a companion metadata file from an export sitting beside the image, a camera-generated filename with the date encoded in it, or a run of neighboring photographs whose dates bracket the missing one. These are reconstructions from evidence, and they should be presented as such rather than as facts.

In the worst case there is genuinely nothing: a re-encoded image with an empty Exif block, no companion file, and a filename assigned by whatever app last handled it. Scans of prints arrive in this state too, having never had a capture date to begin with. Here the correct output is not a guess. It is the admission the specification itself makes room for.

Those three cases want three different treatments, and telling them apart is most of the work — which is what our walkthrough on fixing wrong photo dates is organized around: reading every date a file still carries, ranking the evidence, and writing back a corrected capture date only where something in the file supports it.