FileInfo.LastWriteTime discrepancies [Lakshan Fernando]

I recently investigated a customer issue of incorrect time reporting with FileInfo.LastWriteTime and thought of sharing this information in the blog. In the customer case, the last write time was off by about one hour for some files.


We depend on two Win32 APIs to get the file time information, GetFileAttributesEx in the normal case and FindFirstFile if there is a problem with the call to GetFileAttributesEx. One case where we will call FindFirstFile is if there is already an open handle to the specific file. As File Times section on MSDN describes, when writing to a file, the last write time is not fully updated until all handles that are used for writing are closed. This is the most likely reason that the customer saw the last write time reported incorrectly..

Comments (6)

  1. Anonymous says:

    I’m not sure I agree with your diagnosis.

    From my own investigations looking at various different files on my hard disc, plus my searching around on the Internet (e.g. it would seem to have more to do with daylight saving time than with a failure to update files’ times.

    I could be wrong… but I would urge you to do further investigation.

  2. BCL Team says:

    Hi Andrew,

    Thanks for your comments and apologies for the delay in responding to you – I was on vacation till today.

    The time lag can be seen with a simple repro when LastWriteTime is called on a file that has a handle already opened. In the specific customer case, the affected file was a commonly used one in ASP.NET. But I’m interested in your investigation information and it will be great if you can share a small repro of the daylight issue.


    Lakshan Fernando

  3. Anonymous says:

    Hi Lakshan.  Just spotted your reply.  Certainly if the difference between FileInfo.LastWriteTime and what’s displayed in Windows Explorer is off by exactly one hour, you should strongly consider daylight saving time as a cause.  Will try and come up with a repro when I’m back on my home machine.

  4. Anonymous says:


    Here’s the repro code:-

    File.Create (@"C:File1.txt").Close ();

    File.Create (@"C:File2.txt").Close ();

    File.Create (@"C:File3.txt").Close ();

    File.Create (@"C:File4.txt").Close ();


    new FileInfo (@"C:File1.txt").LastWriteTime = new DateTime (2006, 1, 1, 10, 0, 0);

    new FileInfo (@"C:File2.txt").LastWriteTime = new DateTime (2006, 4, 1, 10, 0, 0);

    new FileInfo (@"C:File3.txt").LastWriteTime = new DateTime (2006, 7, 1, 10, 0, 0);

    new FileInfo (@"C:File4.txt").LastWriteTime = new DateTime (2006, 10, 1, 10, 0, 0);

    I executed this on my home machine this morning (whose location is United Kingdom), and viewed each file’s Date Modified in Windows Explorer.  The time reported for the April, July and October files was what I had set, i.e. 10:00am.  However, the reported time for the January-modified file was 11:00am.

    I’m sure your diagnosis of your customer’s problem was correct, but the mention of the time being out by one hour reminded me of the LastWriteTime/Explorer mismatch due to daylight saving time.

    Hope this helps.  Andrew

Skip to main content