Note that there are some explanatory texts on larger screens.

plurals
  1. POIO.File.GetLastAccessTime is off by one hour
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload