Windows has a daylight savings time bug which results in a conflict during summer time.
For example executing the following commands on a Windows 7 and an NTFS partition in June results in:
U:\>exiftool.exe "-filemodifydate<datetimeoriginal" test.jpg
1 image files updated
U:\>dir test.jpg
17.01.2010 15:15 891.486 test.jpg
But windows explorer reports the modification date with and offset of -1 hour as 17.01.2010 14:15 .
If the same is repeated during winter time e.g. December the time difference disappears.
The reason for this and a solution is described e.g. at
http://www.codeproject.com/Articles/1144/Beating-the-Daylight-Savings-Time-bug-and-getting .
So a direct way to fix this (summer time) problem is by using the library provided with the above article.
I would very much appreciate an implement of this and a fix for this nasty problem?
Wow, bummer.
I will read your reference when I get a chance, but I'm guessing that implementing a fix may be prohibitively painful unless a Perl library is provided.
- Phil
I have good news, and bad news.
First the good news:
- I found a Perl package called Win32::UTCFileTime (http://search.cpan.org/dist/Win32-UTCFileTime/) that supposedly patches the stat() and utime() library functions to fix this Windows deficiency.
Now the bad news:
- The Win32::UTCFileTime routines may be called with a file name only, and don't support being called with a file handle, which ExifTool requires.
- The Win32::UTCFileTime routines don't override the Perl file test operators, so I would need to change all these to stat() calls in the code, which would be ugly.
but here is the real killer:
- On my Windows development machine (XP SP2) with ""Automatically Adjust for Daylight Savings Time" enabled, the ExifTool FileModifyDate matches exactly that reported by Windows Explorer for files on an NTFS filesystem, even when I change the system date/time in and out of DST. But with the Win32::UTCFileTime patch, the stat() times change so they no longer match those reported by Windows Explorer.
This last point is huge. I am guessing that Microsoft changed the time zone handling some time after XP SP2, which makes this a Windows-version-dependent or Windows-settings-dependent problem. Given that ExifTool seems to report the correct FileModifyDate on my development system, I am lothe to change this behaviour and break the backward compatibility for systems like the one I am running.
So the bottom line is that I don't see any good way that I can patch this Windows problem.
- Phil
Edit: I also found this thread (https://exiftool.org/forum/index.php/topic,2949.0/all.html) where this problem was discussed a few years back.
Dear Phil,
Thank you very much for looking into this problem.
After you couldn't reproduce the problem, I was also looking deeper into this.
First of all, I don't believe it is your system, because the article describing the problem I refer to was written in 2001, while the SP2 was released in 2004.
However, what I now realized is that it only seems to occur with certain images. So below I have attached an image which should be able to reproduce the problem.
Please let me know in case it doesn't.
Frank
Hi Frank,
I was just looking at the filesystem date/times in ExifTool and Windows Explorer. I can't see any possible way that these would depend on the content of the file, because ExifTool doesn't even look at the file data when extracting these times. The filesystem date/time for the file may be important (ie. whether it is in or out of the DST range), but this is not preserved when you attach the file in the forum here.
You're right that the problem pre-dates XP SP2. In fact, my tests show this problem does exist with XP SP2. When I change the system date/time in and out of DST, the filesystem date/times reported by ExifTool change, which is definitely wrong. But so do the ones in Windows Explorer. Even though ExifTool reports the wrong date/time, I think this is the correct behaviour since it agrees with what Windows displays. My point is that Microsoft may have fixed Explorer after XP SP2 so that it no longer agrees with ExifTool, but if I fix ExifTool now it won't agree with older versions of Explorer.
- Phil
Hi Phil,
I thought it is extracting this information from the Exif tag.
Frank
Quote from: fkbreitl on October 07, 2013, 09:02:24 AM
I thought it is extracting this information from the Exif tag.
In your initial post you were setting the filesystem FileModifyDate from the EXIF DateTimeOriginal. The problem is on the filesystem side.
- Phil
Yes, that's what I thought I was doing.
Couldn't it be that the DateTimeOriginal tags differ in some way?
However, I don't want to speculate and would prefer to leave the explanation to you.
Here I am just reporting what I am seeing.
If I execute my initial command for the attached photo at a date in June, I see the described time difference.
I am not seeing it for a photo from a different camera. Would you like me to post this as well?
Please try it out, even if you don't believe it.
Frank
PS: Please make sure when using explorer your are looking at the modification date (which is different from the date displayed by default and which you have to activate as additional column in the details view).
Quote from: fkbreitl on October 07, 2013, 09:25:06 AM
Couldn't it be that the DateTimeOriginal tags differ in some way?
Yes, in their content only. The actual date/time you are writing may be significant, but nothing more.
But I'll try your command with the file you gave to see what happens on my system. This will have to wait until tonight when I am back home again.
- Phil
Sorry, I didn't get a chance to drag out the PC last night, but I haven't forgotten.
- Phil
No problem!
OK, I ran the test. As expected, the date/times are consistent on my XP SP2 system (running on an NTFS volume):
C:\>dir PC142081.JPG
Volume in drive C has no label.
Volume Serial Number is C8F0-D326
Directory of C:\
07/10/2013 08:39 AM 276,065 PC142081.JPG
1 File(s) 276,065 bytes
0 Dir(s) 2,981,920,768 bytes free
C:\>exiftool -time:all -G1 -a PC142081.JPG
[System] File Modification Date/Time : 2013:10:07 08:39:54-04:00
[System] File Access Date/Time : 2013:10:08 00:00:00-04:00
[System] File Creation Date/Time : 2013:10:08 18:43:25-04:00
[IFD0] Modify Date : 2011:12:14 16:20:29
[ExifIFD] Date/Time Original : 2011:12:14 16:20:29
[ExifIFD] Create Date : 2011:12:14 16:20:29
C:\>exiftool "-filemodifydate<datetimeoriginal" PC142081.JPG
1 image files updated
C:\>exiftool -time:all -G1 -a PC142081.JPG
[System] File Modification Date/Time : 2011:12:14 16:20:29-05:00
[System] File Access Date/Time : 2011:12:14 16:20:29-05:00
[System] File Creation Date/Time : 2013:10:08 18:43:25-04:00
[IFD0] Modify Date : 2011:12:14 16:20:29
[ExifIFD] Date/Time Original : 2011:12:14 16:20:29
[ExifIFD] Create Date : 2011:12:14 16:20:29
C:\>dir PC142081.JPG
Volume in drive C has no label.
Volume Serial Number is C8F0-D326
Directory of C:\
14/12/2011 04:20 PM 276,065 PC142081.JPG
1 File(s) 276,065 bytes
0 Dir(s) 2,981,920,768 bytes free
And the date/time shown in Explorer is the same. So this seems to work fine for me.
My conclusion is still that the behaviour is system or settings dependent.
- Phil
Thanks Phil! Now I also ran the test on a Windows XP Pro SP3 with an NTFS partition and I was also not able to reproduce the problem there.
However, it occurred on two different Windows 7 systems I tested. So I assume that this problem exists at least for Windows 7.
Do you have a chance to test it on a Windows 7 system as well?
This would be important in order to finally pin down this problem.
Frank
Hi Frank,
I don't have a Windows 7 system.
- Phil
Hi Phil,
That's a pity. However, I found these free Windows 7 images offered by Microsoft for testing Internet Explorer:
http://www.modern.ie/en-us/virtualization-tools
Together with VirtualBox 4.3 (https://www.virtualbox.org/) or Virtual PC this could give you a free Windows 7 test environment.
Frank
Looks like the problem that OP reported still occurs on Windows 10 build 19044.
I ran the following commands:
G:\Documents>exiftool "-filemodifydate#<CreateDate#" sunset.jpg
1 image files updated
G:\Documents>exiftool -G0 -a -s -FileModifyDate -CreateDate sunset.jpg
[File] FileModifyDate : 2023:02:12 17:30:37-05:00
[EXIF] CreateDate : 2023:02:12 17:30:37
G:\Documents>dir sunset.jpg
Directory of G:\Documents
02/12/2023 06:30 PM 4,821,484 sunset.jpg
So right now we're in daylight saving time, and the "dir" command shows a modified timestamp that is one hour ahead of the FileModifyDate that ExifTool reports. Although in Windows Explorer, the "Date modified" column for sunset.jpg shows "2/12/2023 5:30 PM".
Microsoft is dedicated to maintaining backward compatibility at the expense of progress, which means that bugs like this are "features" that will never get fixed.
- Phil
It looks like maybe the behavior has changed actually. OP reported that the timestamp in his Windows Explorer was one hour off. My Windows Explorer shows a timestamp that matches what ExifTool reports, but the "dir" command is showing a timestamp that is one hour ahead.