photoTakenTime: the Date Field in Google Takeout JSON
photoTakenTime is the field in each Google Takeout .json file that holds the date a photo was taken, as Unix seconds in UTC. How to read and use it.
photoTakenTime is the field in each Google Takeout .json file that holds the date and time the photo was taken. Its timestamp value is a Unix time: the number of seconds since 1 January 1970, in UTC. It is the date Google Photos showed for the photo, including any date you corrected by hand, so it is the right date to write back into the photo.
What it looks like
Open a sidecar such as IMG_5512.HEIC.supplemental-metadata.json in Notepad or TextEdit. The field looks like this:
"photoTakenTime": {
"timestamp": "1689438227",
"formatted": "Jul 15, 2023, 4:23:47 PM UTC"
}
timestampis the value to use. Note that it is a string in quotes, not a number, so a script must convert it.formattedis the same moment as readable text, always in UTC. It is for people, and its format depends on the language of the export. Do not parse it.
1689438227 is 15 July 2023, 16:23:47 UTC. In Paris (UTC+2 in summer) the photo was taken at 18:23:47 local time. In New York (UTC−4) it was 12:23:47.
photoTakenTime vs creationTime
The same file has a second date that looks similar:
| Field | Meaning | Use it for the date taken? |
|---|---|---|
photoTakenTime | When the photo was taken, as Google Photos showed it | Yes |
creationTime | When the file was uploaded to Google Photos | No |
For a phone photo backed up the same minute, photoTakenTime and creationTime are almost equal. For a scan of a 1985 print uploaded in 2020, they are 35 years apart. Scripts that copy creationTime put old photos on the upload day.
Where Google gets photoTakenTime
Google takes it from the photo's own EXIF date when the photo has one. When it has none, as with screenshots, chat images and some scans, Google uses another source, such as the file date or the upload time. When you change the date in Google Photos ("Edit date & time"), the new date goes into photoTakenTime, not into the photo file.
That is why the JSON file is often better than the photo: it contains corrections that the file does not.
How to convert the timestamp to a date
Windows (PowerShell):
[DateTimeOffset]::FromUnixTimeSeconds(1689438227).LocalDateTime
Mac (Terminal): date -r 1689438227
Linux: date -d @1689438227
Excel or Google Sheets, with the timestamp in A1: =A1/86400+DATE(1970,1,1) gives the UTC date and time. Format the cell as date and time.
Python:
import datetime, json
data = json.load(open("IMG_5512.HEIC.supplemental-metadata.json"))
ts = int(data["photoTakenTime"]["timestamp"])
print(datetime.datetime.fromtimestamp(ts, datetime.timezone.utc))
The time zone problem
EXIF DateTimeOriginal stores local wall-clock time with no zone. photoTakenTime stores an exact moment in UTC. To write one into the other, a tool must choose a time zone.
Most tools use the time zone of the computer that runs them. That is right for photos taken at home and a few hours off for photos taken in another time zone. Writing the offset into the EXIF tag OffsetTimeOriginal as well keeps the exact moment on record. Is Google Takeout missing time zone information? explains this in detail.
Is photoTakenTime always right?
It is as right as Google Photos was. Three cases deserve a check:
- A camera with the wrong clock. If the camera was set to the wrong year, the EXIF date was wrong, and Google copied it.
- Screenshots and chat images. Their
photoTakenTimeis often the time the file was saved or uploaded, which is usually close enough. - Scans. Unless you corrected the date in Google Photos,
photoTakenTimeis the scan or upload date, not the date of the print. Scanned photos: set the real date and place shows how to set it.
How to write photoTakenTime into the photos
exiftool reads the JSON directly and calls the field PhotoTakenTimeTimestamp:
exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" "-DateTimeOriginal<PhotoTakenTimeTimestamp" "-FileModifyDate<PhotoTakenTimeTimestamp" -overwrite_original "Takeout/Google Photos"
-d %s tells exiftool that the value is in Unix seconds. Run it a second time with "%d/%F.json" for exports made before 2024. It skips sidecars whose names Google cut off, and (1) duplicates; the exiftool guide shows how to handle them. Videos need the QuickTime date tags as well.
The free tools GooglePhotosTakeoutHelper Neo and immich-go also read photoTakenTime.
Takeout JSON Metadata Fixer does it with no command line on Windows, Mac and Linux: it matches every photo to its JSON file, writes photoTakenTime into the EXIF date and the file dates in your computer's time zone, records that offset in OffsetTimeOriginal, and sets the QuickTime dates of videos.
The first 500 photos are free. How to merge Takeout JSON metadata into your photos compares all three ways.
Frequently asked questions
Why is photoTakenTime a few hours off?
It is not. It is in UTC. Converted to your local time zone, it matches the time on the camera.
What if photoTakenTime is 0 or missing?
That is rare. Use the EXIF date in the photo if there is one, otherwise the file date, or set the date by hand.
Is photoTakenTime in milliseconds?
No. It is in seconds. A value with 13 digits would be milliseconds; Takeout uses 10 digits for current dates.
Does photoTakenTime include my manual date changes?
Yes. It holds the date Google Photos showed at the time of the export.