iPhone photos sometimes save the incorrect EXIF:OffsetTime* values

[delerious]

I have a script uses ExifTool to check for inconsistencies in timestamps.

One problem it found with some iPhone 14 Pro photos (I haven't run it on photos taken with earlier versions of the iPhone to see if they also have the problem) is that sometimes the photos will have incorrect EXIF:OffsetTime, EXIF:OffsetTimeOriginal, and EXIF:OffsetTimeDigitized values.

For example, I was in a museum in San Diego's Balboa Park, and I took over 500 photos. About 250 of those photos have the wrong EXIF:OffsetTime* values. San Diego is supposed to have a time zone offset of -08:00, but for those 250 photos, they have the EXIF:OffsetTime* values set to either -07:00, -06:00, or -05:00.

Interestingly, when the EXIF:OffsetTime* values are wrong, the EXIF:DateTimeOriginal, EXIF:CreateDate, and EXIF:ModifyDate values are wrong too. However, if you try to calculate the UTC time from the incorrect EXIF:DateTimeOriginal and EXIF:OffsetTimeOriginal values, you will always end up with the correct UTC time.

For example, if I took a photo at 11:00am local time, that means the EXIF:DateTimeOriginal should be something like "2023-01-01 11:00:00" and the EXIF:OffsetTimeOriginal should be "-08:00". But the photo might be saved with an incorrect EXIF:DateTimeOriginal value of "2023-01-01 14:00:00" and an incorrect EXIF:OffsetTimeOriginal value of "-05:00". But when you calculate the UTC time using those incorrect values, you still get the correct UTC time.

This problem also happened with some photos I took at the San Diego International Airport, which is fairly close to the museum in Balboa Park. But the problem did not happen with any photos I took in other parts of San Diego or any part of Los Angeles (I did not go to any airports in LA).

I wonder if this problem is airport related? Because I noticed the same problem with some photos I took at a Houston airport and a Washington, DC airport.

[Phil Harvey]

I can't help here because I don't know how iPhone determines your time zone.  Is there a setting that allows you to specify the time zone?  It seems like the automatic time zone determination doesn't work very well.

- Phil

[delerious]

Yes the iPhone does have a setting that lets you set the time zone, however mine is set to "Set Automatically", and I do have Location Services turned on, and the Camera app is set to "While Using" for Location Services.

I was thinking this problem maybe had to do with Airplane Mode, because I saw a thread on another forum where someone said their photos taken in Airplane Mode all had the time zone offset set to their home time zone. But that wouldn't explain this problem, because my photos are tagged with 4 different time zones. And my understanding is that GPS will still work if your phone is in Airplane Mode.

Another thing to note is that the iPhone 14 Pro I used doesn't have any cellular service. But again, GPS should still work without any cellular service.

I guess the GPS time was just inaccurate near those 3 airports for some reason? At least the GPS coordinates are accurate - I plotted the Composite:GPSPosition value on a map for one of the photos from the museum with an incorrect time zone offset, and it showed me the correct museum in San Diego.

[Steerpike]

I'd like to add my experience with this exact issue, and provide additional information. 

I took over 1,000 photos with the iPhone 15 Pro in Europe. 30% of them have the wrong EXIF timestamp, and - just like the OP - I noticed that the three 'OffsetTime' EXIF entries were incorrect for the 'bad' timestamps.  But in my case, the locations were random and not related to airports, etc. One set of images were taken at the beach in Barcelona, and another set in Montserrat (mountain area close to Barcelona).

In one case, I took 4 images in sequence, and their timestamps were as follows:
IMG_2011 - timestamp = 02:19:45 (I was asleep at 2:19 so obviously incorrect)
IMG_2012 - timestamp = 11:25:31
IMG_2013 - timestamp = 02:25:59 (taken 19 seconds after the previous one)
IMG_2014 - timestamp = 11:28:09

Focusing on the two images IMG_2012 and IMG_2013 - taken 19 seconds apart and from the exact same location - here's a composite image of two screenshots of the two images from the iPhone: (I'm having difficulties getting the images to show; forgive my inexperience with this forum):


https://imgur.com/a/aSi8DJL


and here's a snapshot of a spreadsheet I put together comparing the two EXIF data elements:


https://imgur.com/a/2s1uVQW

As you can see, for the 'good' timestamp, the OffsetTime is +2:00, while for the 'bad' timestamp, the OffsetTime is -7:00.  I live in California where -7:00 would be appropriate but I was in Spain where +2:00 is appropriate.

What's interesting about this particular image pair is that they were taken from the exact same spot, only 19 seconds apart, which tends to eliminate issues such as GPS quality, etc. Note also that both images are correctly showing the location in Barcelona - so no GPS issues. 

These are just two examples; I have dozens more, and there is no obvious reason for those incorrect offsets.

In addition to tracking down the root cause, does anyone have a simple script or process to follow to correct these bad timestamps?  The process would be something like - find all images where 'OffsetTime' = -7:00; change OffsetTime to +2:00, and add 9:00 to the existing DateTime values.

Edit To Add - I just noticed ... I uploaded all these photos into 'Google Photos' and it sorts them all correctly, and shows all the timestamps correctly (if you turn on the 'info' side panel) - so for example, on IMG_2013, which has an EXIF timestamp of 02:25 and an offset of -7:00, it shows "Sun, 11:25am, GMT +2:00" - exactly the same as for IMG_2012.  So Google Photos is somehow able to figure out what's going on!  I primarily use 'IrfanView' to quickly view my images, and I use it's ability to sort by 'date taken', but it is getting totally thrown by the distorted dates/offsets.

[StarGeek]

So Google Photos is somehow able to figure out what's going on

Do the images have GPS data? Because Google Photos uses that to figure out the time zone regardless of any time zone data that is actually in the file.

[Steerpike]

So Google Photos is somehow able to figure out what's going on

Do the images have GPS data? Because Google Photos uses that to figure out the time zone regardless of any time zone data that is actually in the file.

Absolutely. If you look at the first image I posted, both images are perfectly located in Barcelona.  The EXIF data for image IMG_2012 is as follows (IMG_2013 differs only by 19 seconds):

DateTimeOriginal - 2024:09:22 11:25:39
DateTimeDigitized - 2024:09:22 11:25:39
OffsetTime - +02:00
OffsetTimeOriginal - +02:00
OffsetTimeDigitized - +02:00

GPSTimeStamp - 9  25  39
GPSDateStamp - 2024:09:22

So it appears the GPSTimeStamp is 'UTC' - 9:25:39 am, while the DateTimeOriginal is UTC + OffsetTime.

May I ask you - how do you best post an image here in this forum, so the image actually appears? Above I pasted IMGUR links, which is 'functional', but I'd much rather have images appear 'inline', which I see is happening in your signature.

PS - also - if Google Photos uses GPS data to determine date/time for sorting, what does it do when it encounters an image that doesn't include GPS data?  I'm asking because I've also loaded some images into GP that were scanned photos and obviously didn't have GPS data.

[StarGeek]

So it appears the GPSTimeStamp is 'UTC' - 9:25:39 am, while the DateTimeOriginal is UTC + OffsetTime.

Yes, GPS time stamps are supposed to be UTC. The EXIF time stamps such as DateTimeOriginal are supposed to be the local time where the image was taken

May I ask you - how do you best post an image here in this forum, so the image actually appears? Above I pasted IMGUR links, which is 'functional', but I'd much rather have images appear 'inline', which I see is happening in your signature.

There are two ways to do it. The image I use in my .sig is hosted on imgur. Since I reuse a lot of the images in my posts, I'll use imgur rather than attach the same image over and over.

You have to get the direct link to the image and copy that. Then, click the button above the text box, to the right of the YouTube button. If you mouse over the button that looks like a Polaroid photo, it says "insert an image". Paste the URL and option width or height, and the BBCode will be added at the current cursor location. It will look like this
[img]https://i.imgur.com/i6Bk030.png[/img]

The second way is to attach it to the post. For that, you have to hit the "Reply" or "Quote" button, or if you use the quick reply text box, you have to hit "Preview". Then see the instructions in this post. The BBCode to inline the image will be added at the current cursor position and will look something like
[attach id=5644 width=500]firefox-2024-07-17_07.04.11.png[/attach]

PS - also - if Google Photos uses GPS data to determine date/time for sorting, what does it do when it encounters an image that doesn't include GPS data?  I'm asking because I've also loaded some images into GP that were scanned photos and obviously didn't have GPS data.

If the image doesn't have any GPS data and doesn't have any time zone data, then Google does some stuff to add a time zone and I was never able to figure out exactly what it did. I do know it uses some javascript or something for files without any date/time values and somehow grabs the file system modify date. And then I think it gets the computer's time zone and uses that. But I'm not 100% sure.

It's been a long time since I tried to figure out the Google stuff and because of inconsistencies and Google constantly changing things that I gave it up as I was spending too much time on it and it wasn't something I was using anyway.

[Steerpike]

There are two ways to do it. The image I use in my .sig is hosted on imgur. Since I reuse a lot of the images in my posts, I'll use imgur rather than attach the same image over and over.

You have to get the direct link to the image and copy that. Then, click the button above the text box, to the right of the YouTube button. If you mouse over the button that looks like a Polaroid photo, it says "insert an image". Paste the URL and option width or height, and the BBCode will be added at the current cursor location. It will look like this
[img]https://i.imgur.com/i6Bk030.png[/img]
...

So I thought that's exactly what I did. However - my mistake was to use the 'grab link' / 'copy link' option in Imgur (which I believe copies the 'image link') rather than the 'direct link' option. Once I grab the 'direct link', everything works. I don't use Imgur that often so always have to experiment with which link to copy. Thanks!

So here are the two images under discussion, 


and here's an extract from the exif data for them:



and here's another extract that shows the GPS EXIF data:


So to automate a correction, I guess I could somehow find all images that have an 'OffsetTime' of -07:00, and for those images, set the 'DateTime...' values to be 'GPSTimeStamp + 02:00, and also set the 'OffsetTime...' fields to be +02:00.  Technically I'd need to worry about making such adjustments that cross the midnight boundary but in practical terms, all of my pictures were taken during the day and adding +2 it not going to cross that boundary.  I used to be a programmer but I wouldn't know where to begin writing a program to make this change ... but that's a challenge for another day.

Thanks again for your help.

[StarGeek]

So I thought that's exactly what I did. However - my mistake was to use the 'grab link' / 'copy link' option in Imgur (which I believe copies the 'image link') rather than the 'direct link' option.

Yes, that's an easy mistake to make. The first link leads to the Imgur "post" and as you found out, you have to use the direct link to inline an image.

But that does remind me of the time when a lot of very useful web forums broke because Photobucket started charging to allow inlined images. I need to 1) backup those images, and 2) think of a more future-proof way to keep the images safe.

So to automate a correction, I guess I could somehow find all images that have an 'OffsetTime' of -07:00

You could use
-if '$OffsetTimeOriginal eq "-07:00" '
(reverse the quotes '→" "→' if on Windows CMD)

[Cici]

PS - also - if Google Photos uses GPS data to determine date/time for sorting, what does it do when it encounters an image that doesn't include GPS data?  I'm asking because I've also loaded some images into GP that were scanned photos and obviously didn't have GPS data.

Hi Steerpike, I'm working on entering metadata for a huge scanning project, so I thought I might be able to help. When the location is known, I am assigning GPS coordinates to my images, but when not known, I also wondered how Apple Photos and Google Photos treated such images. So I performed two tests:

Test#1: Updated MWG Date tags with ExifTool + the GPS Date tags. (No GPS coordinates)
Test#2: Updated MWG Date tags with ExifTool (No GPS Date tags and No GPS coordinates)

Result: Both images are assigned the correct date/time/time zone offset in Apple Photos and in Google Photos. Note: The images were taken in February on the East Coast, so Standard Time, i.e. -05:00. Interestingly, when I viewed the time zone in Apple Photos and in Google Photos, it was set to Bogota, Columbia. I have never been to Bogota, Columbia. I'm guessing both applications chose the Bogota, Columbia Standard Time Zone because Bogota doesn't observe Daylight Savings Time, so the time zone offset will remain static for the images. When I don't know the location, I am just defaulting to Eastern Time and setting the offset to either -04:00 or -05:00 dependent on the image date.

I have developed a process to assign the correct time zone offset to my images. So far, it will accommodate any date going back to 1900 and any location in the 50 states. Earlier, my approach was too complicated so I gave up, but I had a lightbulb moment the other night and now it is simple and perfect. It requires a list of specific locations (Tbl_Place w/ Time Zone) and the attached Tbl_Offset table. In the Tbl_Offset, for time zones that observe Daylight Savings Time, there are 3 records, 1) 1/1/2024 - Standard Time Ends, 2) Daylight Time Begins - Daylight Time Ends, 3) Standard Time Begins - 12/31/2024. There may also be a State exception row for states that don't observe Daylight Savings Time in a Time Zone that is observant. Historically, the number of records may vary. My primary data table includes the image date, the time zone and the state. The time zone and state values are populated from the Tbl_Place reference table.

The expression to return the correct offset to my primary data table is:

(Please note: In the expression below, I corrected the "State Exception" column name to "State" to match the attached file. The key point to note about this column is that these states are the exception, not the rule. I also named the data range to Tbl_Offset to align with the expression and re-attached the file.)

=XLOOKUP(1,
  (Tbl_Offset[TZ] = [@TZ]) *
  ([@Date] >= Tbl_Offset[OffsetBegins]) *
  ([@Date] <= Tbl_Offset[OffsetEnds]) *
  (
    (Tbl_Offset[State] = [@[TZ-State]]) +
    ((Tbl_Offset[State] = "") * (COUNTIFS(Tbl_Offset[TZ], [@TZ], Tbl_Offset[State], [@[TZ-State]]) = 0))
  ),
  Tbl_Offset[TZoffset],
  "",
  0,
  1)

Note: I use a CSV to update my image and pdf file metadata.

Hope this helps or at least gives you some ideas.

Time Zone Offsets.xlsx
 

[Steerpike]

So to automate a correction, I guess I could somehow find all images that have an 'OffsetTime' of -07:00

You could use
-if '$OffsetTimeOriginal eq "-07:00" '
(reverse the quotes '→" "→' if on Windows CMD)

Thanks for this info about quotes; I have spent hours reading through documentation and examples, and this is the only place I see any reference to the need to adjust quotes!  For the record, is it only Windows CMD that requires this adjustment?  There are so many examples on the internet and it's not always clear for what platform they are written.

I've done some test updates and I think I've got the basic syntax down; but I'm struggling with how to achieve the following. In 'pseudo-code', I would like to do this:

if OffsetTimeOriginal = "-07:00"
then DateTimeOriginal = GPSDateTime + 02:00

(that is - add two hours to the GPSDateTime composite tag and write it to the DateTimeOriginal tag).

I'm simply not able to figure out how to set one tag based on the contents of another tag plus a constant.

I simplified the command down to
"exiftool -if "$EXIF:OffsetTime eq '-07:00'" "-DateTimeOriginal<GPSDateTime" img_1840.jpg"
and this worked, but as soon as I try to 'add 2' (02:00) to the value, I get an error. I tried all kinds of variants with quotes, etc, but nothing worked. EG:
exiftool -if "$EXIF:OffsetTime eq '-07:00'" "-DateTimeOriginal<GPSDateTime+'02:00'" img_1840.jpg
and
exiftool -if "$EXIF:OffsetTime eq '-07:00'" "-DateTimeOriginal=GPSDateTime+'02:00'" img_1840.jpg

I also realize there are some 'TimeShift' functions - I was hoping to avoid that level of complexity but if that's the only way to achieve what I need, then I'll open that avenue.

Also - If I use the command:

exiftool -time:all -G1 -a -s img_1840.jpg

I see that there are a LOT of time-related fields, beyond the 'EXIF' fields I'm focusing on now (eg, File dates, GPS dates, XMP dates, etc). I presume, for consistency, I really should update ALL of them otherwise I'll be scratching my head a few years from now when some new tool starts reading those wrong values. But GPS date should not change as it's correct already so is there a way to update 'most' but not 'all' dates?

Thanks for your help!

UPDATE - I think I figured out a way - would be interested to know if there are other ways, as I was exploring above (one field + a constant) but this did seem to get me what I needed:

xiftool -if "$EXIF:OffsetTime eq '-07:00'" "-AllDates+=09:00" img_1840.jpg 

What I wanted originally was:
if OffsetTimeOriginal = "-07:00"
then DateTimeOriginal = GPSDateTime + 02:00

But by adding +9:00 to the current date(s) actually achieves the same end result. I'd feel better adding 2:00 to the GPS time ...

I still need to answer my question about all the 'other' date fields, like the XMP dates ...

[Phil Harvey]

I have spent hours reading through documentation and examples, and this is the only place I see any reference to the need to adjust quotes!

Interesting.  It is mentioned 2 times in the application documentation, and 3 times in the FAQ.  Plus, I have mentioned it about 25000 times in this forum (22000 in my signature and an estimated 3000 more time in my responses).

For the record, is it only Windows CMD that requires this adjustment?

As far as I know, yes.

I don't have time right now to work through your other questions.

- Phil

[StarGeek]

Interesting.  It is mentioned 2 times in the application documentation, and 3 times in the FAQ.  Plus, I have mentioned it about 25000 times in this forum (22000 in my signature and an estimated 3000 more time in my responses).

Just because I'm curious (not trying shame/embarrass, just writing down for future use)
Reading examples
Writing examples
FAQ #12
FAQ #19
FAQ #21
FAQ #28

And as I often post exiftool solutions in other places, many of my posts on StackExchange sites and Reddit will also have this as it is one of my standard copy/paste texts.

Part of the problem is that this something that is very specific to the operating system used. And quite often this is information left out of most people's initial posts. And it does require people to have some specific knowledge of the command line they are using.

To add to the problem on Windows, the default command line is most often PowerShell, which has completely different rules in regard to quotes than either CMD or Mac/Linux command lines. Here's an example, where a standard command that works on CMD or Mac/Linux with the only change being the quotes, doesn't work either way on PowerShell. It's been so frustrating that I will no longer help with PS commands, only telling people to switch to CMD.

Now, on to your other question

I've done some test updates and I think I've got the basic syntax down; but I'm struggling with how to achieve the following. In 'pseudo-code', I would like to do this:

if OffsetTimeOriginal = "-07:00"
then DateTimeOriginal = GPSDateTime + 02:00

(that is - add two hours to the GPSDateTime composite tag and write it to the DateTimeOriginal tag).

There are a couple ways to do this.
Edit: Your time shift solution is another one
For singular tags, you can use the ShiftTime helper function
exiftool -if "$OffsetTime eq '-07:00'" "-DateTimeOriginal<${GPSDateTime;ShiftTime(2)}" img_1840.jpg

Or to globally affect all date/time tags, use the GlobalTimeShift option
exiftool -GlobalTimeShift 2 -if "$OffsetTime eq '-07:00'" "-DateTimeOriginal<GPSDateTime" img_1840.jpg

"exiftool -if "$EXIF:OffsetTime eq '-07:00'" "-DateTimeOriginal<GPSDateTime" img_1840.jpg"
and this worked, but as soon as I try to 'add 2' (02:00) to the value, I get an error. I tried all kinds of variants with quotes, etc, but nothing worked.

Math (or string manipulations) can't be down outside the context of a tag. It has to be done inside the tag contaxt using the Advanced formatting feature. That is what is happening above with the ShiftTime helper function

I also realize there are some 'TimeShift' functions - I was hoping to avoid that level of complexity but if that's the only way to achieve what I need, then I'll open that avenue.

Yes, it is what is needed.

Also - If I use the command:

exiftool -time:all -G1 -a -s img_1840.jpg

I see that there are a LOT of time-related fields, beyond the 'EXIF' fields I'm focusing on now (eg, File dates, GPS dates, XMP dates, etc). I presume, for consistency, I really should update ALL of them otherwise I'll be scratching my head a few years from now when some new tool starts reading those wrong values. But GPS date should not change as it's correct already so is there a way to update 'most' but not 'all' dates?

One thing to do is to not tie your change to a exact tag. In the above example, you used EXIF:DateTimeOriginal. This will change only the EXIF:DateTimeOriginal, not any of the other possible DateTimeOriginal tags. The change I made was to remove the EXIF: part. This allows the command to update all tags with that name.

This part of my advice to keep tag names simple. Don't be specific with a tag name unless you know what you are doing.

The best way to update the most important tags is to use the AllDates shortcut. AllDates includes the three most important EXIF timestamps, CreateDate, DateTimeOriginal, and ModifyDate. And because it isn't specifically tied to the EXIF group, it will also update tags with the same name in other groups.

In regard to the file system time stamps, you shouldn't worry too much about them unless a program you are using requires it. Unfortunately, some photo apps will use the file system time stamps instead of the embedded ones. In those cases, you would update the file system time stamps.

Also note that the file system time stamps are always local time. The file system stores the data as UTC and then adjusts the date based upon the local time zone set by the computer.

[Steerpike]

Interesting.  It is mentioned 2 times in the application documentation, and 3 times in the FAQ.  Plus, I have mentioned it about 25000 times in this forum (22000 in my signature and an estimated 3000 more time in my responses).

Just because I'm curious (not trying shame/embarrass, just writing down for future use)
Reading examples
Writing examples
FAQ #12
FAQ #19
FAQ #21
FAQ #28

And as I often post exiftool solutions in other places, many of my posts on StackExchange sites and Reddit will also have this as it is one of my standard copy/paste texts.

Part of the problem is that this something that is very specific to the operating system used. And quite often this is information left out of most people's initial posts. And it does require people to have some specific knowledge of the command line they are using.

To add to the problem on Windows, the default command line is most often PowerShell, which has completely different rules in regard to quotes than either CMD or Mac/Linux command lines. Here's an example, where a standard command that works on CMD or Mac/Linux with the only change being the quotes, doesn't work either way on PowerShell. It's been so frustrating that I will no longer help with PS commands, only telling people to switch to CMD.

Thanks for all the excellent info and advice!  exiftool is clearly an impressive and powerful tool (and excellently supported in this forum!); I only tend to have need for it every few years, and find myself having to re-install (and re-learn!) it each time because I have a new computer since the last time! I'm an old programmer but this type of command line scripting was never my strong point. I do enjoy the challenge, though.

I do see, in your first reference above ('reading examples') the statement: "Also note that Windows users must use double quotes instead of single quotes as below around arguments containing special characters." but having read your comments above, it's more subtle than just 'windows users' - it sounds like the guidance applies to 'windows CMD' use, but if you use PowerShell, all bets are off! I am trying, in general, to get more familiar with PowerShell but in this case I was using CMD, so it seems like I avoided even more confusion!  Also - while advising people to use 'double quotes' is great advice, it's not necessarily obvious (to me as a casual, occasional user) that you ALSO need to switch double quotes to single quotes!  Your specific, explicit direction: (reverse the quotes '→" "→' if on Windows CMD) was the magic bullet for me.

...
One thing to do is to not tie your change to a exact tag. In the above example, you used EXIF:DateTimeOriginal. This will change only the EXIF:DateTimeOriginal, not any of the other possible DateTimeOriginal tags. The change I made was to remove the EXIF: part. This allows the command to update all tags with that name.

This part of my advice to keep tag names simple. Don't be specific with a tag name unless you know what you are doing.

The best way to update the most important tags is to use the AllDates shortcut. AllDates includes the three most important EXIF timestamps, CreateDate, DateTimeOriginal, and ModifyDate. And because it isn't specifically tied to the EXIF group, it will also update tags with the same name in other groups.

If I use the shortcut 'AllDates', it sounds like I'm updating EXIF:CreateDate, EXIF:DateTimeOriginal, and EXIF:ModifyDate. But ALSO - thanks to the 'same name in other groups' feature - I'm updating XMP:CreateDate, XMP:ModifyDate.

But what about the fields IFD0:ModifyDate and XMP-photoshop:DateCreated - I see these latter two items when I issue the command "exiftool -time:all -G1 -a -s".  The XMP-photoshop entry presumably won't get updated.  I have no idea what that field is for but I do occasionally use Photoshop so is that something I should explicitly add for 'completeness'?

From what I understand now, all my problems with this set of files was caused because 'OffsetTime* was getting set, arbitrarily/randomly for some files, incorrectly to -07:00 and not +02:00, so I need to adjust those three fields also. Hopefully there aren't any other instances of those fields lurking in the metadata.

In regard to the file system time stamps, you shouldn't worry too much about them unless a program you are using requires it. Unfortunately, some photo apps will use the file system time stamps instead of the embedded ones. In those cases, you would update the file system time stamps.

Also note that the file system time stamps are always local time. The file system stores the data as UTC and then adjusts the date based upon the local time zone set by the computer.

I first became aware of this issue with my files when I tried to view them in IrfanView, which is still my favorite 'no frills' image viewer. IrfanView allows you to sort by various means, and (because Apple messes with the createDate all the time) I had it set to sort by EXIFDate (Options / sort file list / by EXIF Date (date taken). This has always been rock-solid but this time, the images were clearly out of order, and that's what led to me me discovering the bad OffsetTime* values.

As an aside, I loaded the images into Google Photos and it shows the correct local time despite the 'offsets' being messed up. How it does this, I can't imagine!

Thanks again!

Quick follow-on question - I just looked through a previous directory of iPhone photos, to see if I could find any other occurrence of this issue (I could not).  But I did see a LOT of images in one folder that had 'OffsetTime*' set to 'Z'.  Not ALL images, but All after a certain point in time. We were in Iceland at the time. There are a few images with 'OffsetTime*' set to +01:00, which is accurate, and then a bunch with 'Z'.  I've seen references to 'Z' in some GPS contexts in the Exiftool documentation, but couldn't find any explanation.  ANSWER - it seems 'Z' is for Zero or Zulu, designating an offset of 00:00. Does one always see 'Z' in place of 00:00 in exif data?

Another follow-up, as there are no responses yet; in Exiftool, I see references to
CreateDate; DateTimeOriginal; ModifyDate.

But in IrfanView, the labels are:
DateTime; DateTimeOriginal; DateTimeDigitized.

I realize this is a forum for exiftool and not IrfanView, but as a general discussion about EXIF tags, why are two of the three fields referred to differently? I presume the three fields are the same in both tools.  I guess the actual fields are simply 'codes', not labels, and the labels applied to these codes can vary?

Beyond compare (another of my favorite tools), uses CreateDate, DateTimeOriginal, ModifyDate in one view of exif data, and DateTime, DateTimeOriginal, ModifyDate (CORRECTION: DateTimeDigitized) in another view of exif data!

[StarGeek]

I only tend to have need for it every few years, and find myself having to re-install (and re-learn!) it each time because I have a new computer since the last time! I'm an old programmer but this type of command line scripting was never my strong point. I do enjoy the challenge, though.

This is totally understandable. Most people don't care about the intricacies of metadata and when everything works correctly, they don't need to.

At the very basic level, exiftool isn't that hard. Most of the time, you are either setting a tag to a value e.g. "-DateTimeOriginal=2024:10:13 12:00:00", or copying the value of one tag to another "-CreateDate<DateTimeOriginal".

There are two main complications, though. First, what is the actual tag name you want to work with. Exiftool currently knows about 28,148 different tags. While the vast majority of these aren't the ones which are actually used, it's still an overwhelming number to deal with. This is where the command in FAQ #3 comes in and a lot of problems can be dealt with by knowing how to use that command.

The second complication is that a lot of things people want to do are much more complex. This is where knowing regular expressions (RegEx) and Perl code helps out.

Your specific, explicit direction: (reverse the quotes '→" "→' if on Windows CMD) was the magic bullet for me.

I usually try to tailor the answer to what the OS they are using. That is, if they mention what the OS is or I can figure it out from the context. I'm more likely to mention swapping the quotes on more general sites like StackExchange.

If I use the shortcut 'AllDates', it sounds like I'm updating EXIF:CreateDate, EXIF:DateTimeOriginal, and EXIF:ModifyDate. But ALSO - thanks to the 'same name in other groups' feature - I'm updating XMP:CreateDate, XMP:ModifyDate.

And possibly others. Video tags have a DateTimeOriginal tag and that would be updated.

But what about the fields IFD0:ModifyDate and XMP-photoshop:DateCreated - I see these latter two items when I issue the command "exiftool -time:all -G1 -a -s".  The XMP-photoshop entry presumably won't get updated.  I have no idea what that field is for but I do occasionally use Photoshop so is that something I should explicitly add for 'completeness'?

IFD0:ModifyDate is the EXIF ModifyDate tag and would get updated. And it is one of the main reason I say to keep things simple. Some cameras will write this to IDF1 instead of IDF0, with the result being that people, not knowing better, will only update IFD1:ModifyDate when they should be updating IFD0:ModifyDate.

XMP-photoshop:DateCreated would have to be updated separately. And this also brings up the madness of competing standards (see xkcd Standards). DateCreated is the equivalent of the EXIF:DateTimeOriginal, not the EXIF:CreateDate. This is according to the IPTC Photo Metadata Standard. But CIPA, the source of the EXIF standard, also have an EXIF for XMP standard, which links the XMP tags with their corresponding EXIF tags. In this standard, the EXIF:DateTimeOriginal corresponds to the XMP-exif:DateTimeOriginal.

The IPTC standard is the more wildly used standard, and most of the EXIF for XMP standard tags aren't used because the original EXIF tags are more common and usually have priority.

See this post for the purpose of each of the EXIF time stamps.

As an aside, I loaded the images into Google Photos and it shows the correct local time despite the 'offsets' being messed up. How it does this, I can't imagine!

I would guess that the images have GPS data in them. Google overrides any time zone embedded in the file and looks up the time zone of the coordinates.

But I did see a LOT of images in one folder that had 'OffsetTime*' set to 'Z'.  Not ALL images, but All after a certain point in time. We were in Iceland at the time. There are a few images with 'OffsetTime*' set to +01:00, which is accurate, and then a bunch with 'Z'.  I've seen references to 'Z' in some GPS contexts in the Exiftool documentation, but couldn't find any explanation.  ANSWER - it seems 'Z' is for Zero or Zulu, designating an offset of 00:00. Does one always see 'Z' in place of 00:00 in exif data?

Yes, the Z stands for Zulu Time, which is UTC.

Setting any of the EXIF:OffsetTime* tags to "Z" would be in error. The format is supposed to be ±HH:MM. This is only for the EXIF time stamps. XMP time stamps can have the ±HH:MM format or Z to indicate UTC.