Date/time shift stopped working

[rankamateur]

On a trip to Europe the second week of October, we neglected to change the time zone on our camera (from Pacific Daylight Time to Central European Time), and so ended up with all of our files showing creation times nine hours off.   When we returned, we discovered and downloaded and installed Exiftool (version 8.67 for Mac OSX), and with it we successfully adjusted AllDates on all of the image files with the command exiftool "AllDates+=0 9:0:0" [dir] .  Success.  However ...

This past weekend (October 30) my spouse visited our son's family, and took dozens of pictures of our grandson; on return, I discovered that the camera's date had been set to December 1, 2011 (I do not know why).  Having learned Exiftool syntax, I thought the fix would be as easy as it was for the European pictures.  In fact, I was able to go back in history within Mac Terminal and retrieve the exact command that I had used for the nine hour timeshift  and (yesterday, November 2) I simply edited the former command to exiftool "AllDates-=0:1:0 0" [dir] , figuring I could get the dates adjusted back in one pass from December 1 to November 1, then use a second pass to cross the month boundary from November 1 to October 30 without having to learn whether I could set the date -=0:0:32. 

But when I executed the above command, the date/time of both the creation date/time and last modified date/time for all the files was amended to the time the command was executed (November 2, yesterday afternoon, at the h:m:s that I executed the command); it was not, as I had attempted to do, date-shifted by one month, and not left with the h:m:s time stamp left unaltered. 

Is the problem that the date in the metadata of the files that I am trying to change is a date that is in the future, rather than a date in the past, or is there a different error that I have not yet discovered? 

[Phil Harvey]

I think there is some confusion between date/time values in the metadata of the file itself, and date/time values stored in your filesystem.  See FAQ number 24 for an explanation.

Use this command to see exactly what date/time tags are stored in the file:

exiftool -time:all -a -G1 -s FILE

and let me know if you have any questions after reading the FAQ and running this command.

- Phil

[rankamateur]

Phil Harvey responded, I think there is some confusion between date/time values in the metadata of the file itself, and date/time values stored in your filesystem.  See FAQ number 24 for an explanation.

Apparently I was confused.  After reading your response and FAQ #24, I ran the command exiftool "-AllDates-=0:0:32 0 DIR against the directory that contained the image files recorded when the camera was mistakenly set to December 1.  (The hour argument proved tricky because Daylight Savings Time will end during the time interval between October 30 and December 1, so not only was the date in error, but the time in the metadata of the original files appeared to be one hour early.)   After the operation, I executed your suggested syntax exiftool -time:all -a -G1 -s FILE against one of the files in the directory, and it showed  the time of command execution [System] FileModifyDate as today (November 3, afternoon), but the correct time-when-image-exposed values for October 30, hour, minute, second for [IFD0] ModifyDate, [ExifIFD] DateTimeOriginal, and [ExifFD] CreateDate.   If I correctly understand FAQ #24, I can rationalize the system date, h:m:s to the EXIF metadata date, h:m:s with the command exiftool "-filemodifydate<datetimeoriginal" DIR .

I still wonder why, when I shifted the AllDates values -32 days for all of the images exposed in the Pacific time zone on October 30 (when the camera mistakenly was set to December 1), the Finder app shows the date, hour, and minute of the command's execution for Date Modified and Date Created (as stated in FAQ #24); but, two weeks ago, when I shifted +9 hours to the AllDates values for all of the images exposed in France, the Mac OSX file system displayed the true (CET) time of Date Modified and Date Created in the Finder application, even though I did not use the -P option.  What could account for the different results?
 
Thank you for your prompt assistance.

[Phil Harvey]

I don't think I can explain your observations.  I can't think if how the FileModifyDate would not get set to the current time unless you use -P or set it explicitly.

I don't have time to run this test right now to see if I can replicate this phenomenon, but I will try to repeat your steps when I get a chance.  What version of Mac OS are you running?

- Phil

[rankamateur]

Snow Leopard (version 10.6..

[Phil Harvey]

Sorry for the delay in responding.

I tried -alldates-=0:0:32 and -alldates+=9 on a group of 60 files with different creation dates, without the -P option.  Of these images, only 43 contained date/time tags that were affected by this command, so the others were not written.

All of the files that were not written retained their filesystem creation and modification dates (as expected).

All of the 43 files that were written had their filesystem creation and modification dates set to the current date/time (as I expected, but this is what I was testing).

My tests were run on OS X Lion (10.7.2) because I didn't have a Snow Leopard system handy, but I wouldn't expect this to change between these versions.

So I can not explain your observations.  I suggest that maybe you didn't edit the files as you thought you did.  But if your can reproduce your results under more controlled conditions, please let me know.

- Phil