Why a Google Takeout export shows the wrong dates

The date is in the JSON, and only one of its fields is right

Each photo's JSON has two dates. photoTakenTime is when the photo was taken. creationTime is when it reached Google Photos, which can be years later for anything backed up from an old hard drive. immich-go, GooglePhotosTakeoutHelper and GPTH_Neo all read photoTakenTime and none of them uses creationTime for the date. FixMyTakeout does the same: the timestamp value, in seconds since 1970 in UTC, and never the localized formatted text next to it.

Most photo apps do not read these JSON files (PhotoPrism is the exception, and only for the older names). They read the tags inside the photo (EXIF DateTimeOriginal for pictures, the QuickTime header for videos). When those are empty, Immich, PhotoPrism and Synology Photos fall back to the file's modified date, which in an unfixed export is not the day the photo was taken.

Which files have no date inside them

• Screenshots. Many are PNGs with no capture date inside, so the JSON is the only place the date survives.
• Images received through messaging apps, many of which strip EXIF before sending; a name like IMG-20190704-WA0012.jpg tells you the day but nothing more.
• Many videos, particularly ones saved by an app rather than recorded by the camera.
• Anything whose date you corrected in Google Photos. The correction is in the JSON's photoTakenTime; if the file still carries the camera's original date, an importer reading the file gets the old one.
• Scans, downloads and photos saved from the web, which arrive with no capture date at all.

A photo straight from a phone camera usually does carry its own date, so the damage is uneven: the camera roll looks fine and the screenshots, the forwarded photos and the corrected ones are scattered.

Which date FixMyTakeout writes

The default rule trusts the camera when it agrees with Google. If the file already has a date that differs from photoTakenTime only by a whole number of quarter hours (up to 14 hours either way), the two describe the same moment in different zones and the camera's date is left untouched; the report says camera date kept (matches Google). Any other difference, or no date at all, means Google's date is written into the file. The option "Always use Google's" skips the comparison and writes Google's values everywhere, which is the setting to use if you corrected dates or places in Google Photos and want the files to follow.

For files without any JSON the order is: keep the file's own date if it has one; otherwise take a date from the file name; otherwise leave it and report none found.

Time zones: the JSON does not have one

The timestamp is an instant in UTC. What EXIF stores is a local clock reading, so a zone has to be chosen to turn 07:12 UTC into a wall-clock time. A comment in immich-go issue #652 (February 2025) notes that the sidecar "does not contain timezone information". GPTH_Neo writes the UTC reading with OffsetTime set to +00:00 unless you pass its --local-timezone flag, which it added after issue #145 with the note that Google Photos ignores the offset tag.

FixMyTakeout picks the zone per photo. When the photo has coordinates, the zone comes from those (a 07:12 UTC photo taken in Lisbon is written as 08:12 in summer, one taken in Athens as 10:12). When it has none, the zone you choose on the page is used, and the default is this computer's. Either way the offset is written alongside the date, in OffsetTimeOriginal and OffsetTimeDigitized for photos and in Apple's Keys:CreationDate for videos, so an app that understands offsets can recover the exact instant. The time_zone column of the report shows which zone each file got and whether it came from location or from your setting.

Dates in file names, for files with no JSON

When neither the JSON nor the file has a date, the name often does. FixMyTakeout reads these patterns, which are the ones GooglePhotosTakeoutHelper and immich-go read:

PXL_ names are read as UTC, the choice immich-go makes in its Pixel parser; GooglePhotosTakeoutHelper reads them as local time, and the two tools can disagree by several hours on the same file. A name that gives only a day is deliberately not written into the file, because a made-up time of day would be a false precision that a later tool would trust.

The cost of guessing badly is real: the reporter of GooglePhotosTakeoutHelper issue #353, whose exports had the newer JSON names the tool did not recognize, was left with photos dated in 1868 and 2068 by the name guesser. GPTH_Neo adds a final fallback of 1 January of the year in the folder name. FixMyTakeout stops at none found instead of inventing a date, so the zip entry keeps whatever date the file already had.

Patterns from GPTH's guess_extractor.dart and immich-go's pixel.go; the 1868 and 2068 dates from GPTH #353.

Find the files that will be wrong in your export

1. Run the export through FixMyTakeout and open fixmytakeout-report.csv.
2. Sort by date_before. Every row reading none is a file your photo app would have dated by its file date alone; date_written shows what it has now.
3. Filter date_source for none found. Those files had no JSON, no embedded date and no date in the name, and are the ones to date by hand after import.
4. Spot-check a screenshot and a forwarded photo in your photo app: they are the files most likely to have moved.