Daylight Savings Time Bug of Windows

[fkbreitl]

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:

Code Select Expand

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?

[Phil Harvey]

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

[Phil Harvey]

I have good news, and bad news.

First the good news:

• I found a Perl package called 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 where this problem was discussed a few years back.

[fkbreitl]

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

[Phil Harvey]

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

[fkbreitl]

Hi Phil,

I thought it is extracting this information from the Exif tag.

Frank

[Phil Harvey]

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

[fkbreitl]

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

[fkbreitl]

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).

[Phil Harvey]

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

[Phil Harvey]

Sorry, I didn't get a chance to drag out the PC last night, but I haven't forgotten.

- Phil

[fkbreitl]

No problem!

[Phil Harvey]

OK, I ran the test.  As expected, the date/times are consistent on my XP SP2 system (running on an NTFS volume):

Code Select Expand

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

[fkbreitl]

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

[Phil Harvey]

Hi Frank,

I don't have a Windows 7 system.

- Phil