Why do Explorer and the command prompt interpret file times differently?


A customer observed that if they use Explorer to view the timestamp on a file, it is not always in agreement with the value shown if they run a plain DIR in a command prompt. They are sometimes off by an hour. Why is that?

Whenever you hear the phrase "off by an hour" you should immediately think "Daylight Saving Time".

The formatting of file timestamps shown by Explorer has changed over time. The most recent algorithm (at the time of this writing) is to use the time zone that was in effect at your current location at the time the timestamp was created. For example, a file created at noon in June 22 will show its timestamp as noon, even if you view it in the middle of December. That's because Explorer says, "Well, on June 22, Daylight Saving Time was not in effect, even though it's in effect now, so I will interpret that time zone as if Daylight Saving Time were not active." (Hey, Raymond, didn't you get that backward? Answer: The customer who asked this question is in New Zealand.)¹

The old-style function for converting a UTC timestamp into a local timestmap is File­Time­To­Local­File­Time. The documentation for that function points you at the sequence of operations you need to perform if you want to use the time zone of the timestamp instead of the current time zone.

Explorer switched to using the time zone of the timestamp, but the command processor continues using the old-style conversion.

Why doesn't the command processor get with the program?

Well, for one thing, the people who decide what Explorer does are not the same people who decide what the command processor does. (The Explorer folks can certainly make suggestions, but they can't force the command processor to do anything.) It's like asking why Taco Bell puts the men's room on the left, but Pizza Hut puts it on the right.

The command processor is an old and cranky program. The command processor yells at Explorer to get off his lawn. The command processor gets upset when his Internet connection flakes out while he's watching Matlock online. The command processor doesn't care about your fancy-pants localized file names; it shows the raw file system names. The command processor has hundreds of thousands of scripts, and there's no way of knowing how many of them depend on the exact way it formats dates.

You may be able to wheedle the command processor into making some changes for you, but you'd better have a really good reason, and he's going to be really grumpy about it. The command processor was once cajoled into changing its date format to four-digit years back in the late 20th century, and he did it only because everybody insisted that it was soooooooo important. But he was so grumpy about it, he had an option to go back.

¹ Actually, that's not true. The customer who asked the question was in Texas, but I moved him to New Zealand for the purpose of the story. People in the Southern Hemisphere always have to put up with us Northerners assuming that summer starts in June, so I figured I'd turn the tables for once.

Comments (27)
  1. Grzechooo says:

    Well, that's one of the effects of command processor being underdeveloped.

  2. John says:

    It's like asking why Taco Bell puts the men's room on the left, but Pizza Hut puts it on the right.

    I don't think this analogy quite fits because those things are two separate entities (though I guess they share an owner along with KFC).  Command and Explorer may be considered to be two separate entities internal to Microsoft, but externally they both ship as part of the same product.  I understand the concerns for backward compatibility, but outside of that it would seem desirable for a product to have internal consistency.

  3. Nick says:

    This is your semi-annual reminder that Daylight Saving Time changes in the US this weekend.

  4. Dan Bugglin says:

    @John You could also argue it's in the interest of the parent company to arrange their bathrooms in the same orientation in their properties.

  5. Matthew says:

    Yup, New Zealand. Not Australia or Fiji or whatever. He chooses the important country.

  6. frymaster says:

    @Grzechooo

    As the article says, it's kept the same for compatibility reasons rather than lack of development.

    In any case, there are much better ways to do, for example, scripting - WSH has existed since win95, and powershell since 2006

  7. W says:

    That's why UTC is the ONE TRUE TIMEZONE!!!!!!!!!

  8. xpclient says:

    So what this shows is there are some parts of Windows where MS cares about backward compatibility to such extremes that it halts significant progress on things like the cmd processor. Many parts are never updated. And there are also components where MS just throws backward compatibility out of the window constantly under the name of "progress".

  9. Random832 says:

    And yet, in the DOS days, file timestamps were stored in local time, so it would never have been an issue, and noon on June 22nd would always be noon on June 22nd. Actually, isn't this still true on Fat32? Does that mean that when reading a directory from a Fat32 volume, the kernel converts the timestamps (stored on disk in local time) from local to UTC in anticipation of it being interpreted the way Explorer does it? Or are timestamps no longer in local time on disk?

  10. AndyCadley says:

    @xpclient: Arguably the push to Powershell is about throwing backwards compatibility out in the name of progress. The only real difference is that it's a minimum impact option to leave cmd.exe in there too. The same cannot be said of the GUI, where all new features would somehow also need to be shoehorned into the "old UI" if it were left as an option (or it would be a fairly useless option)

  11. Me says:

    Why haven't both cmd and explorer always worked the new way?

    I feel it's the only correct way. If the file was created at noon, display the file creation time to be noon.

  12. lefty says:

    > It's like asking why Taco Bell puts the men's room on the left, but Pizza Hut puts it on the right.  <<

    Oh my god! I never noticed this before.

    What happens in those combination Taco Bell/Pizza Hut locations that you see everywhere? It must be very confusing.

  13. mikeb says:

    @xpclient:

    Every large organization may have priorities that are different (or even conflicting) in different areas.  MS isn't immune to that effect, and no one should be surprised by that.

  14. Rick C says:

    @W: Sure, because it makes perfect sense for sunrise to be at midnight.

  15. Joshua says:

    [You may be able to wheedle the command processor into making some changes for you, but you'd better have a really good reason, and he's going to be really grumpy about it.]

    Then why doesn't dir /v work anymore? /me ducks.

  16. Random832 says:

    @Rick C

    We're just conditioned to think of midnight as "0:00" rather than as "point halfway between sunset and sunrise". If sunrise is at 0:00, then midnight is at or around 16:00, and what's the problem?

  17. Daniel Neely says:

    @Johnathan

    ... you use a lookup table that was updated yearly by the vendor.  Arbitrary yearly changes in when DST starts/stops don't even rate in time processing WTFery.

    stackoverflow.com/.../why-is-subtracting-these-two-times-in-1927-giving-a-strange-result

  18. Gabe says:

    If you show all times with the current timezone offset, you only need to know the current rule for DST, and there's never any ambiguity as to when two times are.

    If you show all times with the offset that was in effect at that time, you need a database of all DST transition times ever, and there can be confusion as to when certain times actually happened.

    Besides, it's really displaying what the time was in the current timezone at that moment -- it's not showing what the local time was when the file was actually modified (which is what FAT stores).

    It's not hard to understand why they kept the old, simple algorithm for cmd.exe.

  19. Jonathan says:

    Or, you could pick a country like Israel* or Brazil, where DST switch dates are decided yearly by politicians.

    * Actually, Israel switched to a complex yet predictable schedule in 2007, so one can know whether a certain date had DST or not. Still, for dates before that...

  20. Neil says:

    I'm obviously missing something here.

    dir shows me 4-digit years

    dir/4 shows me 4-digit years

    dir/-4 shows me 4-digit years

    dir/2 is an invalid switch

    So what's the option to go back?

  21. kbiel says:

    @xpclient: Perhaps it's because humans tend to be slightly more adaptable than a batch file?

  22. Simon says:

    Actually, NZ is a good example for another reason - being 12 hours ahead of UTC normally, we become *13* hours ahead during Daylight Savings. So don't assume that timezone offsets cannot exceed +/-12:00...

  23. 640k says:

    Also, the old non-standard AM/PM-system can go >12, but the 24h system cannot go >24.

  24. Nigel Tufnel says:

    "Also, the old non-standard AM/PM-system can go >12, but the 24h system cannot go >24."

    I have some work to do... mine only goes to eleven.

  25. "Also, the old non-standard AM/PM-system can go >12, but the 24h system cannot go >24."

    The Japanese seem to be able to do this. If you look at TV listings, you can often find times >24.

  26. TK says:

    @Neal: This isn't really an answer to your question but, at least on Windows 7, the dates shown by the dir command are affected by the regional format settings in the control panel. It will show 2-digit years if the date format is M/d/yy, regardless of whether the /4 option is used.

  27. John says:

    "You could also argue it's in the interest of the parent company to arrange their bathrooms in the same orientation in their properties."

    Come on, now.  They're different buildings with different layouts; who cares where the bathroom is?  It's got a freaking sign on it.  File times are serious business.

Comments are closed.

Skip to main content