Fix Google Takeout Photo Dates on Linux
Fixing a Google Photos export on Linux: exiftool from your distro, ffmpeg for videos, phones through the file manager, and a .deb or .rpm app.
Linux is a good place to fix a Takeout export. Every tool you need is in the package manager, the shell loops are natural, and nothing gets in your way. It also has a couple of quirks the Mac and Windows guides do not mention.
The problem is the same
Unpack the export and every photo is dated the moment you ran unzip. Nautilus, Dolphin and Thunar sort by modified time, and modified time is now. The real dates are in the .json sidecars beside each photo, and no file manager reads them. Google Takeout photos show the wrong date explains why Google does this.
Two Linux details. First, there is no created date to worry about. ext4 stores a birth time but nothing uses it, so tools that write FileCreateDate skip it here and nothing is lost. Second, unzip and file managers set modified time to now, but bsdtar and some archive managers preserve the time stored in the zip, which for Takeout is when Google built the archive. Either way it is wrong, just differently wrong.
Unpack all parts into one folder
cd ~/Downloads
for f in takeout-*.zip; do unzip -o -q "$f" -d ~/takeout; done
-o overwrites the duplicated album metadata.json files without asking. Count the zips against the Takeout page first, and check none is short. Takeout split into many zip parts has the details. Make sure the drive has room for twice the download.
exiftool, the free path
sudo apt install libimage-exiftool-perl # Debian, Ubuntu, Mint
sudo dnf install perl-Image-ExifTool # Fedora
sudo pacman -S perl-image-exiftool # Arch
Then, from the folder above Takeout:
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" \
"-DateTimeOriginal<PhotoTakenTimeTimestamp" \
"-FileModifyDate<PhotoTakenTimeTimestamp" \
-ext jpg -ext jpeg -ext png -ext heic -overwrite_original -progress "Takeout/Google Photos"
Repeat with "%d/%F.json" for older exports. Set TZ first if your photos were mostly taken somewhere other than the machine's zone, for example TZ=Europe/Berlin exiftool ..., because the sidecar is UTC and EXIF has no zone.
That handles the well-behaved files. Truncated sidecar names, (1) duplicates, -edited copies and videos each need their own pass, and the exiftool guide has a loop for each. If you would rather have a script do the matching, GooglePhotosTakeoutHelper publishes a Linux binary and handles the naming quirks.
If all you want is the file manager to sort correctly and you do not care about EXIF, touch does it from the sidecar with a few lines of shell and jq, but the date then lives only in the filesystem and is lost on the next copy. Writing EXIF is worth the extra step.
Videos
MP4 and MOV keep their date in the QuickTime container, not EXIF, and exiftool needs different tags for them:
exiftool -r -d %s -api QuickTimeUTC -tagsfromfile "%d/%F.supplemental-metadata.json" \
"-CreateDate<PhotoTakenTimeTimestamp" "-TrackCreateDate<PhotoTakenTimeTimestamp" \
"-MediaCreateDate<PhotoTakenTimeTimestamp" "-FileModifyDate<PhotoTakenTimeTimestamp" \
-ext mp4 -ext mov -overwrite_original "Takeout/Google Photos"
Old AVI, 3GP and WMV files from early phones do not play in most modern galleries. ffmpeg converts them, and on Linux it is one package away: sudo apt install ffmpeg or sudo dnf install ffmpeg (Fedora needs RPM Fusion enabled). iPhone MOV files are already H.264 and only need re-wrapping, which is instant and loses nothing:
ffmpeg -i IMG_4698.MOV -c copy -movflags +faststart IMG_4698.mp4
Convert old AVI, WMV and 3GP videos to MP4 covers the ones that need real re-encoding.
HEIC
Most distro image viewers open HEIC once libheif and its GNOME or KDE plugin are installed, but Windows machines and older Android phones you may share with will not. heif-convert from libheif-examples converts, and exiftool copies the EXIF across afterwards. Convert HEIC to JPG and keep the metadata has the commands.
Phones
An Android phone plugged in shows up in the file manager through MTP, courtesy of gvfs or kio. Copy the organized photos into DCIM and the gallery picks them up. MTP is slow and does not preserve file timestamps, so the date must be in EXIF for the phone's gallery to sort correctly. That is one more reason to write EXIF and not only touch.
The app
Takeout JSON Metadata Fixer ships for Linux as a .deb and an .rpm, with the Java runtime and the HEIC decoder inside, so there is nothing else to install.
sudo dpkg -i photo-organizer_1.4.0-1_amd64.deb
It installs to /opt/photo-organizer with a desktop entry, and sudo apt remove photo-organizer takes it away again. Without root, the unpacked build runs from anywhere under your home folder. It works on any distro from Debian 10 or Ubuntu 18.10 onward, on Wayland or X11.
Point it at the zips or the unpacked folder. It matches every photo to its sidecar, including the truncated and (1) names, writes the date and GPS into EXIF and the file's modified time, sets the QuickTime tags on videos, keeps Live Photo pairs together and converts HEIC to JPG with its bundled decoder. Video conversion uses your distro's ffmpeg when it finds one in PATH; without it, videos are copied as they are. A phone mounted by the file manager shows up as an export target.
Dry run first, then the real run. It is offline apart from optional place-name lookups, and the licence key that unlocks unlimited photos is checked locally. Free for 500 photos, $9.99 once for unlimited.
Frequently asked questions
Does the app need root?
Only to install the package. The unpacked build runs from your home folder with no root at all. Processing your photos never needs it.
Will it work on Arch, NixOS or Alpine?
There is no native package for those, but the unpacked build is a folder with a launcher in bin/, and it runs anywhere glibc 2.28 or newer is present. Alpine uses musl, so it is out.
Why does exiftool ignore FileCreateDate on Linux?
Because Linux has no portable way to set a file's birth time. exiftool writes it on Mac and Windows only. It does not matter; nothing on Linux sorts by it.
Can I run the whole thing on a headless server?
exiftool and GooglePhotosTakeoutHelper, yes. The app is a desktop program and needs a display, though it works fine over a remote desktop session or with a monitor plugged in for the afternoon.