#41 {mtime} daylight saving under xp sp3

[Liviu]

Running rhash v1.3.0 stock win32 build under xp sp3.

Not sure it's a bug per se, but looks different from entrenched windows usances. The timestamp rhash displays for the first file is the "true" one (i.e. the respective local time back in last December). Yet, windows has long had this odd behavior of adjusting all timestamps based on the current daylight saving state, which makes rhash's timestamps to fall one off vs. those displayed by the cmd prompt 'dir' (and windows explorer, and virtually everybody else).

---

C:\tmp>dir /a-d *.exe
12/26/2012 03:00 AM 304,582 rhash-1.2.10.exe
09/17/2013 02:08 AM 315,552 rhash-1.3.0.exe

C:\tmp>rhash-1.3.0.exe --md5 --printf=%{mtime}\t%s\t%p\n -- *.exe
02:00.58 2012-12-26 304582 rhash-1.2.10.exe
02:08.48 2013-09-17 315552 rhash-1.3.0.exe

C:\tmp>

---

Liviu

[Aleksey]

Can't reproduce the bug on Win7 x64, nor on NTFS nor on a FAT disk.

The problem probably is caused by incorrect FILETIME returned by the GetFileAttributesEx() call for files on FAT (FAT stores times in local time), see the MSDN article "File Times":
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

I'm closing the bug because MS droped WinXP support. But if you write a patch, I consider it ;)

[Liviu]

The bug still exists, it only looks different during the winter months ;-) when DST is off. The following is the output of two identical runs on an NTFS volume - except for the current date, first one outside DST, second one inside DST - copied from a Win7 x64 cmd prompt (run-as-admin in order for 'date' to work).

---

C:\tmp>date /t
Thu 12/26/2013

C:\tmp>dir /a-d *.exe
12/26/2012 02:00 AM 304,582 rhash-1.2.10.exe
09/17/2013 01:08 AM 315,552 rhash-1.3.0.exe

C:\tmp>rhash-1.3.0.exe --md5 --printf=%{mtime}\t%s\t%p\n -- *.exe
02:00.58 2012-12-26 304582 rhash-1.2.10.exe
02:08.48 2013-09-17 315552 rhash-1.3.0.exe

C:\tmp>date 9/21/13

C:\tmp>dir /a-d *.exe
12/26/2012 03:00 AM 304,582 rhash-1.2.10.exe
09/17/2013 02:08 AM 315,552 rhash-1.3.0.exe

C:\tmp>rhash-1.3.0.exe --md5 --printf=%{mtime}\t%s\t%p\n -- *.exe
02:00.58 2012-12-26 304582 rhash-1.2.10.exe
02:08.48 2013-09-17 315552 rhash-1.3.0.exe

---

Note that the 'dir' times shift by 1 hour, while the 'rhash' times stay the same. They match when the system date/time is in the same DST on/off state as the file timestamp itself - December in the first run, September in the second run. Without digging too deeply, I guess that the CRT 'localtime' works correctly (which rhash uses), while 'cmd' uses FileTimeToLocalFileTime incorrectly, against MS' own advice (http://support.microsoft.com/kb/129574).

I think rhash is doing it right, so no patch warranted, but maybe a FAQ "if rhash displays some timestamps one hour off in Windows vs. cmd/explorer/etc, then that's just a known MS quirk".

[Aleksey]

By experimenting I've got that on Win7-x64 localtime() makes the same wrong conversion as the mentioned FileTimeToLocalFileTime() function, returning the same time as the Windows 'dir' command.

Only Windows Explorer applies DST correctly.

So it's really bug in the OS (in WinAPI and in the MS implementation of C library).