FileModifyDate as in Exif:DateTimeOriginal feature

[coz]

Bogdan,

I love your program.  Thank you for creating it and to Phil for the underlying ExifTool.  The older version had the FileModifyDate as in Exif:DateTimeOriginal Option that allowed us to reset the Windows properties dates that would otherwise change once we modified anything.  This was a very useful feature

Is this feature hidden or is it coming back in a future version?   In the meantime, are there any detrimental effects by using version 3.38 after using version 4.02 to modify settings (time shift)

Thanks!
Chris

[BogdanH]

Hi Chris,

I've started GUI v4 as "minimal" as possible, knowing that I'll probably need to bring back some previously existing options. I just needed to know which of them are "important" enough. FileModifyDate option is will be back in next update.
Thank you for feedback.

Bogdan

PS: No, there should be no problem if you switch between v3 and v4. You can actually have both in the same folder -just rename one of them to i.e. ExifToolGUIold.exe (so each GUI will create/use it's own ini file).

[coz]

Bodgan,

Thanks, that's great news.

Chris

[coz]

Bodgan/Phil,

Thanks for putting this feature back in v4.03.  However, when I use it, it seems that it shifts the FileModifyDate to one hour later than the Exif date.  I also tried this in v3.38 and it does the same thing.

I searched the forums and found the following thread in the archives.  I tried adjusting the "Automatically Adjust for Daylight Savings Time) in my system (win7) but there is still an offset.   

https://exiftool.org/forum/index.php/topic,2128.15.html

I do not profess to understand this but the last post by Phil mentions a Windows specific path setting.  Has this been implemented and does GUI reference this path?   

Finally, will Preferences, especially "preserve DateModified of files" be included in a future release?   Thanks!

Chris

[Phil Harvey]

Hi Chris,

The current version of ExifTool includes the Windows-specific patch which is supposed to fix the time offset problem.

Could you give more details about the problem?  You say you are shifting date/time values.  What is the initial date, what are you shifting it by, and what is the result?

- Phil

[BogdanH]

Hi,

Yes, what happens is (I'm using DateTimeOriginal here):
If DateTimeOriginal contain summer time value, and ExifTool changes FileModifyDate now (meaning, in winter time), then hour value of FileModifyDate is incremented by one hour.
If both, DateTimeOriginal contain winter time value, and ExifTool changes FileModifyDate now (in winter time), then resulting FileModifyDate is the same as in DateTimeOriginal.
I assume (but didn't tried out), if I would execute the same command in summer time, then opposite would happen.

Bogdan

[Phil Harvey]

Hi Bogdan,

Thanks.  This explains a bit, but I still don't know what you are doing.  Are you shifting DateTimeOriginal and FileModifyDate together in one command?  If so, what happens if you shift them individually?

- Phil

Edit: Also, what are you using to extract the FileModifyDate?  Are is the value shown by Windows Explorer the same as that extracted with exiftool?

[BogdanH]

Hi Phil,

I should have been more precise. No, no shifting, just:
exiftool -FileModifyDate<Exif:DateTimeOriginal photo.jpg

Assuming DateTimeOriginal is 2008:08:22 10:36:52. After executing command I get:

Code Select Expand

2008:08:22 11:36:52 -as seen inside Windows Explorer!

When I then do (something like) this:
exiftool -FileModifyDate photo.jpg
...I get:

Code Select Expand

2008:08:22 10:36:52+02:00
About +02:00... I assume, there's 1h for winter time and 1h for my TimeZone(?).

Bogdan

[Phil Harvey]

I understand now, thanks.  At least exiftool is self-consistent, which is the problem that was addressed by the patch.

I'll see if I can determine the source of this discrepancy.

- Phil

Edit: One question:  What timezone does Windows think you are in?

[BogdanH]

My timezone (also used in Windows) is UTC +01 hour (Slovenia, Austria, Germany,..)

Wait! It's not Exiftool -it's GUI!
It's getting late now here... I'll check this out tomorrow evening.

Added False red alert above..
I've checked anyway (couldn't wait). The thing is, that in Windows Explorer there are some predefined ways of showing data about files. If directory is a "images directory", then some DateTime values shown are taken from Exif (and are thus mixed with FileModifyDate values).
No, FileModifyDate issue has nothing to do with GUI.

Bogdan

[Phil Harvey]

OK, I just took a test file and ran these two commands:

exiftool -filemodifydate="2010:07:01 02:03:04" FILE

and

exiftool -filemodifydate="2010:12:01 02:03:04" FILE

And in both cases, Windows explorer showed "2:03 AM" for Date Modified.  ExifTool showed "02:03:04-04:00" for the first file, and "02:03:04-05:00" for the second file, which is correct since we are now off daylight savings time and EST is 5 hours behind GMT.

I was running Windows XP and ExifTool 8.41.  In the Windows Date and Time control panel I had "Automatically adjust clock for daylight savings changes" turned on.  If I turn this off and repeat the two commands, Windows Explorer shows the same (correct) times, and ExifTool shows "02:03:04-05:00" for both (which makes some sense).

Everything seems to work the way I would expect.  If this problem is specific to Windows 7, I won't be able to reproduce it myself because I don't have access to a Windows 7 machine.

Perhaps someone could test this for me on Windows 7:  What results do the two commands above give for you?  Also, for a file where the Explorer date/time differs from the ExifTool date/time, type "dir FILE" in the cmd.exe window --> does this time agree with Explorer, or ExifTool?

- Phil

[coz]

Paul/Bogdan,

Wow, thanks for looking into this!   I would be glad to help diagnose this since am running Windows 7.  I can run the commands in the post above but do not know the exiftool command to view the time with the GMT offset.   I tried the -ee option but didn't see anything related to time zone or GMT.

By the way, my pictures where taken in May of 2010 in the Pacific time zone.  I had my camera time set on Eastern Time Zone so I adjusted them all (a few days ago) by 3 hours but the File Modify Date is off by 1 hour (presumably because of DST). 

I set my system clock back to October and re-ran the GUI FileModifyDate =Exif:DateTimeOriginal command and then all the times matched.    I guess this is a work-around if nothing else works. 

Chris

[Phil Harvey]

Hi Chris,

Thanks for helping.  The command to view the FileModifyDate is:

exiftool -FileModifyDate FILE

Also, if you could run

dir FILE

it may be useful too.  Thanks.

For these to work, exiftool.exe must be in the current directory or somewhere in your system PATH, and FILE must be in the current directory or contain a directory specification.

One question:  Were there any changes to the implementation of DST in your locale in the last few years?  I'm wondering if the problem may be caused by different versions of the date/time libraries used by Windows and ExifTool.

- Phil

[BogdanH]

Hi Phil,

I believe it's Windows Explorer in Windows 7. Here's how it goes:
Now, in winter time, I execute (doesn't matter if in console window, which I did, or inside GUI):

exiftool -FileModifydate="2007:07:07 10:00:00" photo.jpg

Windows Explorer shows Date Modified=2007:07:07 11:00:00
Dir command in console window shows Date Modified=2007:07:07 10:00:00

Now I change system time to summer time, for example 2010:08:07 18:20:00. Windows Explorer and console still show the same (different hour) date modify value -as expected, though.
While my system is still in summer time, I execute the same exiftool command as shown above.
This time, both, Win Explorer and console show equal (correct) value: 2007:07:07 10:00:00

Note, that my system is still in summer time. Now I execute:
exiftool -FileModifyDate="2007:12:07 10:00:00" photo.jpg
-that is, this time I set file FileModifyDate to winter time month.

This time, what I see is:
Win Explorer shows Date Modified=2007:12:07 09:00:00
Console windows shows 2007:12:07 10:00:00 -which is correct again.

My conclusion: one simply can't trust file modify date in Win Explorer! One would think that this value is ment to be changed by OS only (in this case date modify always contain "when it happened" value). But then, how come that console window doesn't follow this behaviour?
No, dont ask me what I think about MS right now.

Bogdan
PS: The same happens if I change file modify date using Delphi (the prog.language I use for GUI).

[Phil Harvey]

Hi Bogdan,

Thank you very much for running these tests.  It seems fairly conclusive that the problem is with Windows since ExifTool and the built-in "dir" command report the same time, but these disagree with Explorer.

I did some Googling and found this reference which documents a long-standing Windows time zone bug.

excerpt from Microsoft Knowledge Base article Q158588:
"After the automatic correction for Daylight Savings Time, monitoring programs comparing current time/date stamps to reference data that were not written using Win32 API calls which directly obtain/adjust to Universal Coordinated Time (UTC) will erroneously report time/date changes on files."

and a quote from my link above:
"Microsoft picked an incorrect, but unambiguously invertable algorithm: move all times up an hour when daylight time is in effect on the local computer, irrespective of the DST state of the time being converted."

Given this history, it looks like the problem isn't isolated to Windows 7, which makes me wonder why it seemed to work for me on XP (but maybe this is due to a different filesystem, since the reference indicates the behaviour is different on FAT and NTFS systems).

It could be that there is no easy solution to this problem in Windows since ExifTool is limited to using the standard C I/O routines and not the platform-specific Win32 API calls. 

- Phil