Why do my file creation, access, or modified time disappear if I set it to midnight on January 1, 1980?


A customer discovered that if their program used the Set­File­Time function to set a network file's creation, access, or modified time to the specific value of "midnight on January 1, 1980", then the corresponding timestamp is removed. What's up with that?

As you may recall, midnight on January 1, 1980 is a special sentinel value: It is the epoch for the MS-DOS time/date format.

At this point, I believe the responsible thing to do is to speculate irresponsibly.

It appears that the network server they are using is trying very hard to accommodate MS-DOS clients. In particular, if somebody tries to set a file timestamp to midnight January 1, 1980, the server assumes that the client is trying to clear the timestamp.

Explorer is one of those accommodating programs. If it sees a file whose timestamp is exactly January 1, 1980 at midnight, then it assumes that the timestamp came from a FAT filesystem (possibly tunnelled through other file systems along the way, like a network redirector), and treats it as equivalent to a missing timestamp.

Comments (17)
  1. DWalker07 says:

    I wonder how the customer "discovered" this. Why is he setting the file times to that value in the first place?

    There are more important things to worry about! Although, I suppose knowledge is always a good thing.

    1. Kevin says:

      Nothing nefarious here. The customer probably just accidentally passed zero to SetFileTime (instead of some real value), observed the weird Explorer behavior, traced it back to SetFileTime, and then gave up and asked Microsoft for help.

      1. osexpert says:

        If you check the link you see "January 1, 1601 = The value 0 as a Win32 FILETIME. " so January 1, 1980 is a perfectly valid FILETIME. Explorer showing this time as is a bug in my book.

        1. If you decide to show January 1, 1980 as a genuine timestamp, then you introduce a new bug: Explorer shows files with no timestamp on FAT volumes as having a bogus timestamp of January 1, 1980. FAT volumes were kind of important in 1995.

          1. osexpert says:

            I see this more of a limitation than a bug. But how can a file have "no timestamp" anyways? Can you somehow remove the time stamp(s) of files in FAT? Can you have files that are never created/modified/accsessed? It make no sense to me.

          2. Tell that to the POSIX folks. POSIX doesn't have creation timestamps. (It has last access, last modified, and last status change, but no creation.)

          3. Random832 says:

            > If you decide to show January 1, 1980 as a genuine timestamp, then you introduce a new bug: Explorer shows files with no timestamp on FAT volumes as having a bogus timestamp of January 1, 1980.

            If this were really important to deal with, shouldn't it be dealt with in the FAT layer, so that Explorer never sees "January 1, 1980" for these files?

        2. Joshua says:

          They might have called the conversion routine on a zeroed DOS file date/time structure. (I'm too lazy to look up its name.)

    2. DaveL says:

      There are legitimate reasons why people would like to set a file's timestamp pre-1980. For example, users with historical pictures may want to set the file timestamp to match the date that the (original) picture was taken. I believe Explorer's details view doesn't show pre-1980 timestamps because its cached data doesn't have the full information and can't retrospectively be changed. Explorer's file properties dialog shows the correct range of FILETIME values.

  2. osexpert says:

    This post is very confusing. Can you clear the file times with Set­File­Time? Arent't the filetimes always there, builtin the file metadata? Docs for Set­File­Time says nothing about clearing.

    1. Brian_EE says:

      They didn't clear the timestamp. They basically set it to 0. Raymond said: "Explorer is one of those accommodating programs. If it sees a file whose timestamp is exactly January 1, 1980 at midnight, ... and treats it as equivalent to a missing timestamp."

      >Arent’t the filetimes always there
      I would hazard to guess that this is dependent on the source file system. Not everything is stored locally, and non-local storage isn't always a Windows server with NTFS.

      1. cheong00 says:

        It may not be available even on local storage. Say, I have ext3fs IFS installed on my system. (File creation time stamp is added on ext4fs https://en.wikipedia.org/wiki/Ext4#Features )

  3. Alex says:

    Similar hypothesis: a number of buggy programs set the timestamp to zero which showed January 1st 1980 for a bunch of files. Someone complained and since it's pretty unlikely for a file to have an actual timestamp of zero, someone decided not to show the date in that situation

  4. osexpert says:

    BTW: Tried SetFileTime with empty FILETIME for all 3 args. SetFileTime return true but the files time stamps are not changed (bug: SetFileTime should have returned false).
    Tried setting with dwLowDateTime = 1 and then times are set to ‎1. ‎januar ‎1601, ‏‎01:00:00.

    1. Brian says:

      According to the documentation ( https://msdn.microsoft.com/en-us/library/windows/desktop/ms724933.aspx ),
      SetFileTime returns 0 if it fails.

  5. xcomcmdr says:

    > It appears that the network server they are using is trying very hard to accommodate MS-DOS clients.

    This does not mean it's a Windows Server ? In which type of server OS is this behavior embedded ?

    Just being curious.

  6. Charles Dye says:

    It's been a long time, but I'm pretty sure this behavior goes back to MS-DOS 5 (and maybe even earlier.) For files with a date/time stamp of 0, the DIR command would display a blank instead of 1980-01-01 00:00.

Comments are closed.

Skip to main content