The date taken is modified to local time when exporting from Photos

Exporting as Unmodified Originals keeps the exact timestamp because it preserves the HEIC file with its original timezone data. When you export as JPEG, Photos rewrites the “date taken” into your current timezone, which is why London photos shift to Hawaii time.

To avoid the time change every time:

• Use File ➡️ Export ➡️ Export Unmodified Original
• Or use a third‑party exporter that doesn’t rewrite EXIF timestamps

This keeps the correct capture date without any timezone conversion.

Axel F.

Where do you see that "date taken" info? Are you using macOS or maybe Windows? Do you convert .heic to .jpg when transferring from iPhone to the PC which might cause this?

It is normal for the file dates FileCreateDate & FileModifyDate to follow the computer's time zone.

But the internal metadata dates should be preserved. ExifIFD:DateTimeOriginal is the most important and usually IFD0:ModifyDate and ExifIFD:CreateDate are set the same. Newer iOS and iPadOS have also ExifIFD:OffsetTime that should be the time zone. GPS location or the lack of it might affect how Photos.app sorts images. Movie metadata dates are a different matter.

In macOS Internal image metadata date 'ExifIFD:DateTimeOriginal' as well as GPS can be checked outside Photos.app in Finder > View > Show Preview > Show More > 'Content Created' date in the right side panel (this is DateTimeOriginal but for some reason Apple labels it differently here).

Or in Preview.app > Tools > Show Inspector > i > Exif > 'Date Time Original' field which shows also the possible Time Zone info -- GPS info is also in that dialog (File dates, GPS, Title, Headline, Keywords, and Description are displayed in Finder > Get Info).

Windows uses different labels and might sometimes be misleading:

https://exiftool.org/forum/index.php?topic=6591.msg32875#msg32875

Or check dates with exiftool which is the golden standard:

exiftool -a -G1 -s -fileOrder5 FileName -api QuickTimeUTC=1 -api RequestTags=FileCreateDate -Time:All 2026-0218-1349-13.heic
[System]        FileModifyDate                  : 2026:02:18 13:49:13+02:00
[System]        FileAccessDate                  : 2026:03:02 07:58:45+02:00
[System]        FileInodeChangeDate             : 2026:03:02 07:58:44+02:00
[MacOS]         FileCreateDate                  : 2026:02:18 13:49:13+02:00
[IFD0]          ModifyDate                      : 2026:02:18 13:49:13
[ExifIFD]       DateTimeOriginal                : 2026:02:18 13:49:13
[ExifIFD]       CreateDate                      : 2026:02:18 13:49:13
[ExifIFD]       OffsetTime                      : +02:00
[ExifIFD]       OffsetTimeOriginal              : +02:00
[ExifIFD]       OffsetTimeDigitized             : +02:00
[ExifIFD]       SubSecTimeOriginal              : 515
[ExifIFD]       SubSecTimeDigitized             : 515
[GPS]           GPSDateStamp                    : 2026:02:18
[XMP-exif]      DateTimeOriginal                : 2026:02:18 13:49:13
[XMP-xmp]       ModifyDate                      : 2026:02:19 09:20:54+02:00
[XMP-xmp]       CreateDate                      : 2026:02:18 13:49:13.515
[XMP-photoshop] DateCreated                     : 2026:02:18 13:49:13.515
[ICC-header]    ProfileDateTime                 : 2022:01:01 00:00:00
[Composite]     SubSecCreateDate                : 2026:02:18 13:49:13.515+02:00
[Composite]     SubSecDateTimeOriginal          : 2026:02:18 13:49:13.515+02:00
[Composite]     SubSecModifyDate                : 2026:02:18 13:49:13+02:00

Axel Foley wrote:

Exporting as Unmodified Originals keeps the exact timestamp because it preserves the HEIC file with its original timezone data. ...

This used to be, but the Photos.app on the Mac is no longer preserving the original fully unmodified since the introduction of iCloud Photos. when we are merging two PhotosLibraries from different devices in iCloud, duplicates between the tow libraries will be consolidated into one. One of the originals may be lost. Internally, in iCloud, will only one of the duplicate originals remain, with a new, unique filename. The file creation date may be different, when the original will be downloaded again from iCloud. The original filename will be recreated, based on the internal SQLite database files. If the date file creation date of the original image files has been modified with exiftool or another tool before importing them to Photos, the file creation date of the exported original file may be set to January 1, 1970 on export. Quite few of my old family scans are now showing this date, when I export them from Photos.

For example, one old scanned jpeg photo has a creation date of April 16, 1944, set with HoudahGeo before importing it, but is now showing January 1, 1970, when I export the original on macOS Tahoe.

When I adjust the date and time using thePhotos.app, the edited versions will be exported with the adjusted date and time as the file creation date, as long as the date is after January 1, 1970.

I recommend that you provide a direct product feedback to Apple here 👉 Product Feedback - Apple 

Axel F.

I'd recommend setting the iPhone shoot .jpg if you don't want .heic. Then possible .heic to .jpg glitches should not happen. I did not yet test that.

Windows 11 Pro has .heic support built-in but windows 11 Home needs an add-on for .heic and HEVC/H.265 support.

Below is Windows 11 Home/Pro details for that .heic. Windows might use many metadata tags to display "Date taken" so you never know what tag it really displays there:

léonie wrote:

January 1, 1970 on export

Yes, that is the UNIX epoch time zero. UNIX time is the number of non-leap seconds that have elapsed since 00:00:00 UTC on 1 January 1970.

BTW on Sequoia 15.7.4 APFS supports Finder FileCreateDate and FileModifyDate as old as 21.9.1677.

But MacOS Extended supports only down to 1.1.1970 filedates. It is possible to temporarily set those filedates to 1677 but after a reboot or after re-mounting the disk the dates are reverted to 1.1.1970.

I archive images to MacOS Extended formatted HDDs. I have set all filedates to 1970 or later there because otherwise pre-1970 filedates might change causing Carbon Copy Cloner to needlessly backup those files every time I backup the master HDD to other backup HDDs. Of course the internal metadata dates are correct.

So in APFS they look like this:

In images ExifIFD:DateTimeOriginal 0001:01:01 00:00:00 seems to be the earliest that Photos.app supports.

In movies the earliest date 'QuickTime:CreateDate' supports in macOS 14.2.1 Sonoma Photos.app is 1904:01:01 00:00:00 UTC. On the other hand, 'Keys:CreationDate' supports dates as early as 0001:01:01 00:00:00.

léonie wrote: …When I adjust the date and time using thePhotos.app, the edited versions will be exported with the adjusted date and time as the file creation date, as long as the date is after January 1, 1970.

This is disturbing, so I just tried this-- I used Photos to change a 2026 date to 2 February 1942. In Preview, exports show as 1942 for the edited version, and 2026 for the original. Pictures I scanned last year behave the same way-- the original is original, and the edited version reflects the change I made. I'm not looking at Exif-- just using Preview's interpretation. I don't see January 1, 1970.

Tahoe 26.3

Oh, just say Matti's post. All this is APFS Mac drive. 7/4/1776 works.