I recently enabled timezone display in Sonoma Photos.app with:
defaults write NSGlobalDomain AppleICUTimeFormatStrings -dict-add "2" "HH:mm:ss z"
You can revert to the default with:
defaults delete NSGlobalDomain AppleICUTimeFormatStrings
...and then noticed that a few dozen images showed incorrect timezone in Photos for images taken in the winter. They displayed +03:00 instead +02:00 which was incorrect because DST had ended 30.10.2022.
I checked the time tags, and sure enough, OffsetTimeOriginal was somehow incorrectly set at +03:00:
exiftool -a -G1 -s -Time:All image.jpg
[ExifIFD] DateTimeOriginal : 2022:12:24 14:16:42
[ExifIFD] OffsetTime : +02:00
[ExifIFD] OffsetTimeOriginal : +03:00
[ExifIFD] OffsetTimeDigitized : +03:00
I tested and verified that Photos.app gets the timezone from OffsetTimeOriginal and ignores other OffsetTime* tags. I also verified that such incorrect timezone affects sorting. BTW if there is no OffsetTimeOriginal, then GPS location affects sorting. (iOS 15.5 or later do not have GPSTimeStamp anymore, only GPSDateStamp, and it is moved to OffsetTime* tags).
I don't know what workflow might have caused that error. All such images were originally Canon .cr3 images edited with the latest Lightroom to .jpg.
Anyway, I used GraphicConverter 12.0.7 to correct the timezone via Modify Exif Date > Set Exif Date Time Zone...
p.s. After fixing the timezones I used Carbon Copy Cloner to backup the images. But later I had a hunch that the backup went too fast. And sure, enough, CCC did not backup the updated images. Why? Well, CCC looks for changed file size and file modification date when deciding if the file has changed. Just changing such +03:00 to +02:00 does not change file size one bit, and I have set GC to preserve file dates even after editing metadata. CCC has an option to use md5 checksum which fixes this issue but it is quite slow so I do not use that. Instead, I now did a small change to the enclosing folder name so CCC backupped ALL its contents. ...it is a FAQ here why file dates change and are "wrong" but I guess this is one good reason for that!