Estoy trabajando en un programa que graba metadatos de fecha de archivos, como la hora de creación, la última hora de modificación, etc. Una versión anterior del programa está escrita en VBA, y hace algo como esto:IO.File.GetLastAccessTime está desactivado por una hora
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
de salida para el archivo en cuestión:
?getfilelastaccesstime("SomePath")
7/30/2010 2:16:07 PM
Ese es el valor que recibo de las propiedades de los archivos de Windows detonador. Felicidad.
Estoy portando esta funcionalidad a una aplicación VB.Net. El nuevo código:
Public Function GetLastAccessTime(ByVal FilePath As String) As Date
Return IO.File.GetLastAccessTime(FilePath)
End Function
Simplicity itself. La salida:
?GetLastAccessTime("SomePath")
#7/30/2010 3:16:07 PM#
Una hora más tarde.
Ambas funciones se están ejecutando en la misma máquina, verificando el mismo archivo. También intenté usar la clase IO.FileInfo con el mismo resultado. Revisé miles de archivos y se agotaron por una hora. Las otras propiedades de fecha para la hora de creación y la hora de la última modificación también están desactivadas en una hora.
¡Ayuda!
Olvidé mencionar en la publicación original, La zona horaria de la computadora es CST, y el horario de verano no está vigente.
He reproducido el problema en Windows 7 de 64 bits y Windows XP de 32 bits.
Gracias.
1/6/2011 actualización:
Gracias a todos los que sugirieron tratar de calcular la fecha deseada de la UTC usando las compensaciones de zona horaria correspondiente. En este momento, estoy decidiendo que no vale la pena el riesgo de hacerlo. Para este requisito de negocio en particular, es mucho mejor decir que el valor de la fecha no es el que esperabas porque así es como funciona la API. Si intento "arreglar" esto, entonces lo tengo, y preferiría no hacerlo.
Solo por las patadas que traté de utilizar el buen viejo Scripting.FileSystemObject a través de interoperabilidad. Proporciona los resultados esperados que coinciden con Windows Explorer, con una penalización de rendimiento de aproximadamente 5 veces en comparación con System.IO. Si resulta que debo obtener fechas que coincidan con lo que tiene Windows Explorer, voy a morder la bala y seguir esta ruta.
Otro experimento Probé iba directamente a la función API GetFileTime en Kernel32 a través de C#:
[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool GetFileTime(
IntPtr hFile,
ref FILETIME lpCreationTime,
ref FILETIME lpLastAccessTime,
ref FILETIME lpLastWriteTime
);
que resultó en exactamente el mismo comportamiento System.IO tenía, el tiempo estaba fuera por una hora desde el Explorador de Windows .
Gracias de nuevo a todos.
Parece un problema con el horario de verano. – Flipster
El último tiempo de acceso tiene una granularidad de aproximadamente 1 hora. Además, tenga en cuenta que, de forma predeterminada, en Windows Vista y en versiones anteriores, el [Valor de último acceso no se actualiza en volúmenes NTFS de manera predeterminada] (http://blogs.technet.com/b/filecab/archive/2006/11/07). /disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance.aspx). –
DST no está vigente ahora pero * estaba * en vigor cuando se modificó por última vez el archivo. ¿Quién tiene la razón? Trabaja en UTC para evitar tener que hacer esa pregunta. –