Fix UTC timestamp in DateTimeOriginal with DST taken into account

[repaying1255]

Hi Everyone, on/off user of exiftool and it is amazing! Love the batch processing. I am currently cleaning up the pictures of my wife. She had her pictures spread in google photos and in our nextcloud instance. I am working to merge them and get them into a single library to then use something like Immich as the frontend. However, when I was cleaning up the google photos using the sidecar json files to embed the timestamp and then use the timestamp to organize the files I noticed that the timestamp is in UTC and while that didn't surprise me at first what was a surprise is that applications do not assume this timestamp and they just reflect the time as is. So when I looked at 2 images that are the same (1 from google photos and the other from nextcloud) the timestamp in Mac Preview shows the 5 hr difference and I know the picture when it was roughly taken.

Question: Is there a way to fix the DateTimeOriginal timestamp to have the offset or just fix it so that other programs read it correctly?

Below is more detail on what I did. I am using exiftool in docker via alpine hence the mount points.

```
# Merge JSON files from google photos
docker run --rm -it \
-v /mnt/user/storage/Photos/gphotos-amanda:/photos \
-v /mnt/user/storage/Photos/gphotos-amanda-new:/temp \
-v /mnt/user/storage/Photos/gphotos-amanda-final:/final \
exiftool \
-r \
-d "%s" \
-tagsfromfile "%d%F.json" \
-description \
"-GPSAltitude<GeoDataAltitude" \
"-GPSLatitude<GeoDataLatitude" \
"-GPSLatitudeRef<GeoDataLatitude" \
"-GPSLongitude<GeoDataLongitude" \
"-GPSLongitudeRef<GeoDataLongitude" \
"-Keywords<Tags" \
"-Subject<Tags" \
"-Caption-Abstract<Description" \
"-ImageDescription<Description" \
"-DateTimeOriginal<PhotoTakenTimeTimestamp" \
"-FileCreateDate<PhotoTakenTimeTimestamp" \
"-CreateDate<PhotoTakenTimeTimestamp" \
"-FileModifyDate<PhotoLastModifiedTimeTimestamp" \
"-ModifyDate<PhotoLastModifiedTimeTimestamp" \
-ext "*" \
-out "/temp/%d" \
-progress \
--ext json \
-efile! "/temp/error.log" \
-efile2! "/temp/unchanged.log" \
-efile16! "/temp/created.log" \
"/photos"
```

The nextcloud image as a control has this timestamp: Date/Time Original              : 2012:03:17 10:34:27
The google photos image has: Date/Time Original              : 2012:03:17 15:34:27

[StarGeek]

However, when I was cleaning up the google photos using the sidecar json files to embed the timestamp

Warning, make sure you check to see if you actually need to do this. Google does not remove any metadata from your files when you do a takeout. If you are copying data from the JSON files without checking first, you are destroying the original data.

The only time you would need to do this is when you added data on the Google website or the files never had data to begin with, such as screenshots or files downloaded from social media.

Run this command on the files to see the actual embedded timestamps
exiftool -time:all --system:all -G1 -a -s file.jpg

then use the timestamp to organize the files I noticed that the timestamp is in UTC and while that didn't surprise me at first what was a surprise is that applications do not assume this timestamp and they just reflect the time as is.

Most image timestamps are supposed to be set to the local time where the image was taken. Because of this, the applications are correctly reading the data. The major exception is GPS time stamps, as these are supposed to be UTC.

Most video timestamps are supposed to be UTC and a proper app will read this and adjust the outputted time to the local time zone. Windows and Mac do this when you check the properties. But not all programs do.

So when I looked at 2 images that are the same (1 from google photos and the other from nextcloud) the timestamp in Mac Preview shows the 5 hr difference and I know the picture when it was roughly taken.
...
The nextcloud image as a control has this timestamp:

Code Select Expand

Date/Time Original              : 2012:03:17 10:34:27The google photos image has:

Code Select Expand

Date/Time Original              : 2012:03:17 15:34:27

It looks like Nextcloud is correctly reading the data and copying the data from the JSON files is overwriting the original timestamp.

Question: Is there a way to fix the DateTimeOriginal timestamp to have the offset or just fix it so that other programs read it correctly?

The other programs are reading it correctly, so you have to correct the timestamp in the file.

Try this
exiftool -Alldates-=5 /path/to/files/

This command subtracts 5 hours the three most common EXIF timestamps, CreateDate, DateTimeOriginal, and ModifyDate. Change -= to += if you need to add time.

[repaying1255]

Thank you so much! Since reading this post I re-requested the google photos data as I had corrupted a bit the initial golden source data with all my moves (even though I did not edit the metadata DateTimeOriginal timestamp on the real data some other exiftool commands did move files instead of copy them). I am going to compare this new dataset with the nextcloud photos to see what it is up.

One last piece I did forget to mention is the nextcloud photos are not 1:1 with the google photos for some reason as they are not the single source of truth data it is just a good baseline comparison of metadata. Nextcloud seems to have converted files into jpegs and reduced the quality as the test image i mentioned earlier was half the size compared to the google photos image.