3
I have Windows 7 Professional, with automatic updates (so all patches should have been applied). I am in the EST/EDT time zone (New York). The Control Panel time box has "use DST" checked. DST just "sprang forward" on Sunday. I tried applying the patch from last August (KB2863058) and it says it's already installed.
In the Command Prompt (DOS command line) box, "dir" gives what appears to be the correct time for a file I just updated, as well as one updated two months ago (during Standard Time). The clock on the screen lower right corner gives the correct time. However, Windows Explorer gives times one hour earlier for files last modified during Standard Time.
For example,
dir C:\Users\Phil\Desktop\content
gives me
01/24/2014 12:36 PM 4,524 ContentList.txt
while Windows Explorer Desktop > content shows
ContentList.txt 1/24/2014 11:36 AM Text Document
It's an hour off, as though DST hasn't been applied. Is this a known Windows bug? I haven't seen any reports of it. Since "dir" and WinExp agree on a just-modified file, I think it's WinExp that's off. I used Perl's -M $filename (with $^T) to get the age of files in fractional days, and working the age by hand gives a time two hours later than WinExp (13:36 in the above example). I assume 1 hour is accounted for by DST, but the other?
To summarize, for same file (last modified during Standard Time):
Windows Explorer 11:36 AM
Command Prompt 12:36 PM
Perl -M operator 1:36 PM
For a file modified today, all three times are in agreement. Who's right and who's wrong? I would think that various ways of displaying a time should agree on whether DST is applied.
Phil Perry
Posted 2014-03-12T16:47:55.797
Reputation: 254
Additional info: the stat() command (Perl) behaves the same way as -M (presumably both use the C stat() library call). Files last modified during DST (including previous years) seem to show up the same in all cases. Just files modified during Standard Time period (DST off) seem to show up an hour later on -M and stat and dir, as compared to Windows Explorer. – Phil Perry – 2014-03-12T21:54:15.460
I think I have a workaround of, after computing the timestamp (from -M operator), feeding it to localtime() and checking if the $isdst flag is FALSE. If it is, I need to subtract 1 hour (3600 seconds) from the timestamp. However, I would like to know what combinations of DST for "right now" and "file was modified at" need such an update, and if I have to add 3600 seconds if the file was DST and "now" is not DST. Does anyone know for sure? Or, is there a simpler way to do this? – Phil Perry – 2014-03-12T23:16:38.787
If the Windows Explorer one is an hour earlier, doesn't that imply that Windows Explorer is the correct one and that Command Prompt is incorrectly assuming DST? To me, that seems more likely than saying that Command Prompt is correct and Explorer is unnecessarily removing an our. That is especially true because I would guess that Perl is removing an hour (assuming that the reported time is in DST, when it is in fact correct). – Moshe Katz – 2014-03-13T02:10:42.507
@random, kindly do NOT edit my post and completely change the meaning of it! You can spell out small numbers if you like, but you're not entitled to change my writing. You removed the Perl tag, which is important information. – Phil Perry – 2014-03-13T14:47:48.383
@MosheKatz, yes, sorry if it gave the wrong impression. WinExp (11:36 EST) would more likely be correct, than adding an hour to give 12:36 EDT in January (Perl -M operator and stat call, Command Prompt dir). However, I do not know for sure whether the file was last modified at 11:36 EST or 12:36 EST, and so which is correct. Does WinExp not use the system stat() call (which I presume Perl and Command Prompt do)? – Phil Perry – 2014-03-13T14:53:38.867
1Perl is incidental, and it's not what you are having issues with, merely something you are double-checking with. Also, "bug" is not descriptive of your issue. Trying to make it more evident from the title what you are seeing. – random – 2014-03-13T16:10:12.543