title: IO.File.GetLastAccessTime is off by one hour
body: <p>I'm working on a program that records date metadata from files, such as creation time, last modified time, etc. An old version of the program is written in VBA, and does something like this:</p>
  
  <pre><code>Public Function GetFileLastAccessTime(ByVal FilePath As String) As Date
      Dim fso As New Scripting.FileSystemObject
      Dim f As Scripting.File
      Set f = fso.GetFile(FilePath)
      GetFileLastAccessTime = f.DateLastAccessed
  End Function
  </code></pre>
  
  <p>Output for the file in question:</p>
  
  <pre><code>?getfilelastaccesstime("SomePath")
  7/30/2010 2:16:07 PM 
  </code></pre>
  
  <p>That is the value I get from the file properties in Windows Exploder. Happiness.</p>
  
  <p>I'm porting this functionality to a VB.Net app. The new code:</p>
  
  <pre><code>Public Function GetLastAccessTime(ByVal FilePath As String) As Date
      Return IO.File.GetLastAccessTime(FilePath)
  End Function
  </code></pre>
  
  <p>Simplicity itself. The output:</p>
  
  <pre><code>?GetLastAccessTime("SomePath")
  #7/30/2010 3:16:07 PM#
  </code></pre>
  
  <p>One hour later. </p>
  
  <p>Both functions are running on the same machine, checking the same file. I've also tried using the IO.FileInfo class with the same result. I've checked thousands of files and they are all off by one hour. The other date properties for creation time and last modified time are also off by one hour.</p>
  
  <p>Help!</p>
  
  <p>I forgot to mention in the original post, The computer's time zone is CST, and daylight savings time is currently not in effect.</p>
  
  <p>I've reproduced the problem on Windows 7 64 bit and Windows XP 32 bit.</p>
  
  <p>Thanks.</p>
  
  <p>1/6/2011 update:</p>
  
  <p>Thanks to everyone who suggested trying to calculate the desired date from UTC using the appropriate time zone offsets. At this time I'm deciding its not worth the risk to do so. For this particular business requirement, its much better to say the date value is not what you expected it to be because thats just the way the API works. If I attempt to "fix" this then I own it, and I'd rather not. </p>
  
  <p>Just for kicks I tried using the good old Scripting.FileSystemObject via interop. It gives the expected results that agree with Windows Explorer, with about a 5x performance penalty compared to System.IO. If it turns out I must get dates that match what Windows Explorer has, I will bite the bullet and go this route.</p>
  
  <p>Another experiment I tried was going directly to the GetFileTime API function in kernel32 via C#:</p>
  
  <pre><code>[DllImport("kernel32.dll", SetLastError = true)]
  private static extern bool GetFileTime(
  IntPtr hFile,
  ref FILETIME lpCreationTime,
  ref FILETIME lpLastAccessTime,
  ref FILETIME lpLastWriteTime
  );
  </code></pre>
  
  <p>That resulted in exactly the same behavior System.IO had, the time was off by an hour from Windows Explorer.</p>
  
  <p>Thanks again everyone.</p>