Add local time zone export option for correct Apple Photos imports

[curtgrimes]

When a photo in Google Photos with a date of "March 5, 2021 2:35 PM -06:00" is run through this tool and imported into Apple Photos, Apple Photos displays an incorrect date:

In Google Photos	After Apple Photos import (time doesn't match)

This adds an option that allows the photo to be imported into Apple Photos with a time that matches the time recorded in Google Photos:

After Apple Photos import (using new option - time is correct)

Details

Add an option to export files with a DateTimeOriginal in UTC (default, current behavior) or optionally in the system's local time zone. This provides a workaround for an issue where files processed by this tool and imported into Apple Photos may have incorrect dates/times due to Apple Photos always assuming the DateTimeOriginal value (which does not include an offset) is in the system's time zone. If the user knows they will be importing their media into Apple Photos after processing it with MetaSort, they can choose a new option to export files with a DateTimeOriginal in the system's time zone instead of UTC.

A prompt and explanation of UTC vs. system time zone export is displayed to the user. The default is the current behavior of exporting in UTC.

❓ Should timestamps be written in UTC (default) or using your current system time zone offset (-06:00)?

Timestamps get written to the DateTimeOriginal EXIF field. By design, this field does not
contain a time zone offset, only a date and time in the fixed YYYY:MM:DD HH:MM:SS format
(but other fields may contain an offset). Some apps like Apple Photos ignore the offset field
and interpret DateTimeOriginal in the local system's time zone offset. So if a photo
originally taken at "2024-05-05 15:00-05:00" is imported into Apple Photos with
a DateTimeOriginal converted to UTC "2024-05-05 20:00" (notice no time zone offset) on a
system set to a time zone offset of "-05:00", the Apple Photos interface will show that
the photo was taken at "2024-05-05 20:00-05:00" (8 pm in that time zone) instead of
"2024-05-05 15:00-05:00" (3 pm).

Writing the timestamp using the system's time zone offset instead of UTC prevents this shift
and preserves the correct displayed time, as long as you are importing into Apple Photos on
a system using this same time zone offset of -06:00.

How should timestamps be written?
1. UTC (default)
2. System time zone offset (-06:00) (recommended if importing into Apple Photos on a system set to this same offset)

1

✅ Timestamps will be written in UTC.

Or when selecting the new option:

2

✅ Timestamps will be written using the system time zone offset (-06:00).

Steps to reproduce issue

1. Have a Google Photos export from Google Takeout
   1. Or alternatively, create a folder with a minimal sample of a Google Photos takeout:
      1. Create a folder with a sample JPG named photo.jpg.
      2. Give it the expected attribute:

         exiftool -overwrite_original \
             -DateTimeOriginal="2021:03:05 14:35:43" \
             photo.jpg
         

      3. In that folder, create a JSON file named photo.jpg.json with this content:

         {
             "photoTakenTime": {
                 "timestamp": "1614976543",
                 "formatted": "Mar 5, 2021, 8:35:43 PM UTC"
             }
         }
         

2. Run that folder through MetaSort using the How to Use MetaSort instructions.
3. Import the photo into Apple Photos on macOS (drag it onto the Apple Photos window).
4. Go to Apple Photos > Imports > Select the photo > Cmd + I.
5. Expected: The photo's time is 2:35:43 PM, which is what would have been displayed in Google Photos
6. Actual: The photo's time is 8:35:43 PM.

[iamsanmith]

Hi @curtgrimes,

Yes - this feature is definitely required now.

In recent versions of ExifTool, local time is no longer automatically written into DateTimeOriginal when the input value is a UTC timestamp. Earlier, ExifTool would implicitly convert the UTC time (from Google Takeout JSON) into local time while writing EXIF, which made MetaSort’s output appear correct without any extra handling.

That behavior has changed.

Now, ExifTool writes the timestamp as-is, and many viewers (including Google Photos and other gallery apps) interpret and display the value strictly as UTC, even when epoch-based metadata is present. As a result, timestamps appear shifted unless local-time correction is explicitly applied.

So going forward, MetaSort needs to manually apply the local-time offset while converting the epoch timestamp to an EXIF-formatted datetime.

Example

• Original capture time: 2026:02:06 09:06:24 +05:30
• Google Takeout stores this as: 2026:02:06 03:36:24 UTC
• Earlier behavior: ExifTool would automatically convert this back to 2026:02:06 09:06:24
• Current behavior: ExifTool writes 2026:02:06 03:36:24 unless MetaSort explicitly applies the local-time correction

---

Important additional requirement

Even after the user selects a local timezone or the code determines a local time shift, MetaSort must first inspect the original media file for existing timezone metadata.

• If the photo or video already contains a valid local timezone offset
  (e.g. OffsetTimeOriginal = +06:00, which can happen with travel photos),
  that offset must be preserved and no override should occur.

• Only if no local-time or offset metadata exists in the original media file, MetaSort should:

  • apply the user-selected or inferred local-time offset
  • embed the corrected local timestamp and offset explicitly

This prevents travel photos and mixed-timezone libraries from being unintentionally corrupted.

---

This local-time correction logic is only required during epoch → timestamp conversion.
It is not needed for:

• filename-based date guessing
• cases where timestamps are already local and valid

Please double-check that your commit follows this order of precedence:

1. Existing EXIF/XMP local-time metadata (preserve if present)
2. User-selected or inferred timezone (apply only if missing)
3. Fallback behavior (leave as UTC)

Once done, feel free to email me at imsanmith@proton.me so I can verify and test it on my end.

Thanks a lot for the effort and the contribution — really appreciated 🙏

[curtgrimes]

Thank you for your response. Your comment feels like it was written completely by AI (if it was not, I apologize). It's unclear to me if the human @iamsanmith actually reviewed this code, and I don't feel compelled to put more time into this PR for your project because of it. But feel free to work it to completion on your end if you prefer. Thanks.

[iamsanmith]

@curtgrimes hey, yes i used ai to edit my message (to clean format it )

i personally reviewed your whole code so i asked for it