Confidencial de Windows
Evolución de la marca de tiempo de propiedad de archivos
Raymond Chen
En Windows 95, la información de marca de tiempo en la hoja de propiedad de archivos mostrabas las diversas marcas de tiempo en la zona horaria local, incluso si ésa no era la zona horaria activa en ese momento en particular. Por ejemplo, en este momento en Redmond estamos en la hora estándar del Pacífico, de manera que Windows 95 mostraría todas las marcas de tiempo relativas a la hora estándar del Pacífico. Como resultado, la marca de tiempo en un archivo que creó a mediodía del 4 de julio aparecerá como si se hubiera creado a las 11:00 a.m. cuando la vea en el invierno, porque la hora de verano del Pacífico se refiere al mismo momento en el tiempo que las 11:00 a.m. Hora estándar del Pacífico. Cuidado, porque Redmond no estaba usando la hora estándar del Pacífico el 4 de julio, pero la información es técnicamente correcta (si bien intuitivamente incorrecta).
Este tratamiento de las horas que pertenecen “al otro lado” del límite de tiempo del horario de verano es una discrepancia notoria entre código administrado y sin administrar. Históricamente el código sin administrar realiza una conversión entre hora universal coordinada (UTC) y hora local basada en la zona horaria local al momento en que se realiza la conversión, en vez de en la zona horaria que estaba en efecto para la hora que se convierte. Un motivo para esto es que basar la zona horaria en la hora que se convierte puede provocar ambigüedad u horas que no se pueden convertir. Por ejemplo, durante la transición de hora estándar a hora de verano, el reloj se adelanta de 2:00 a.m. a 3:00 a.m. en Estados Unidos. Una hora local grabada como 2:30 a.m. no tendría hora UTC correspondiente, porque no hubo tal cosa como 2:30 a.m. a nivel local. Aún peor, una hora local grabada como 2:30 a.m. durante la transición de hora de verano a hora estándar sería ambigua, porque durante la transición de hora de verano a hora estándar, el reloj retrocede una hora y la hora local 2:30 a.m. tiene lugar dos veces.
Otro motivo para no usar la hora que se convierte para elegir la zona horaria es que en muchos casos el sistema operativo no tiene la información necesaria para saber qué zona horaria estaba en efecto en cierto momento del pasado. Las normas para cambiar entre hora estándar y hora de verano están sujetas a cambio por los gobiernos locales. Además, han habido países (como Israel y Brasil) que, hasta hace poco, no seguían un conjunto predecible de normas sino que decidían acerca de la fecha para el cambio caso a caso. Dado un momento en el pasado o en el futuro, es difícil (o en el caso del futuro, imposible) determinar con certeza qué zona horaria está en efecto en ese momento. (¡Y buena suerte si desea obtener algo entendible para momentos anteriores a la estandarización de las horas!)
Por otra parte, la clase System.DateTime en código administrado hace su mejor esfuerzo para determinar qué zona horaria estaba en efecto para la hora que se convierte y opta por presentar algo más intuitivamente correcto, pero que aún puede arrojar error cuando se presentan los casos inusuales que acarrean contratiempos al código sin administrar.
De vuelta a la evolución. En Windows 2000, el formato de las marcas de tiempo se modificó levemente para decir Ayer, Hoy o Mañana para fechas que se encontraban dentro de un día de la fecha actual. Por ejemplo, en lugar de decir Creado: domingo, 14 de febrero de 2009, 7:00:00 a.m., la hoja de propiedades diría Creado: hoy, 14 de febrero de 2009, 7:00:00 a.m., si se ve el 14 de febrero. No ha cambiado nada esencial; simplemente se trata de un ajuste visual para que las cosas se vean más bonitas.
En Windows Vista, la porción de tiempo de la marca de tiempo se hizo un poco más sencilla: si la hora y la fecha se refieren al día actual, entonces la porción de tiempo de la marca de tiempo se da en una noción relativa: Creado: hoy, 14 de febrero de 2009, hace 15 minutos.
Y más recientemente, en Windows 7, la página General de la hoja de propiedades muestra las marcas de tiempo basadas en la zona horaria que estaba en efecto en su ubicación actual cuando se creó el archivo en lugar de basarse en la hora actual, con lo cual la hoja de propiedades está más alineada con la manera en que el código administrado presenta las marcas de tiempo. Por último, el archivo que creó al mediodía del 4 de julio aparecerá como si se hubiera creado al mediodía incluso durante los meses de invierno. Este cambio aprovecha las llamadas zonas horarias dinámicas, que permiten las normas de la hora de verano para que una zona horaria varíe de año a año. Esto permite que Windows sepa que un archivo creado el 30 de octubre de 2006 en Redmond se creó durante la hora estándar del Pacífico, mientras que un archivo creado el 30 de octubre de 2007 se creó durante la hora de verano del Pacífico, gracias al cambio en las normas de la hora de verano en Estados Unidos que entró en efecto en 2007.
Tenga en cuenta, sin embargo, que la información histórica que viene con Windows no retrocede a años anteriores a 1987, cuando las normas eran diferentes todavía, de manera que es posible que las marcas de tiempo anteriores a ese año terminen mal convertidas.
El resultado de todos estos cambios en la interpretación de las marcas de tiempo es que es posible que el mismo archivo, cuando se ve desde versiones diferentes de Windows, muestre valores que difieren por una hora en cualquiera de los dos sentidos. La marca de tiempo propiamente tal no ha cambiado, sólo la manera en que Windows la representa.
El sitio web de Raymond Chen, The Old New Thing , y su libro del mismo nombre (Addison-Wesley, 2007) tratan de la historia de Windows, la programación Win32 y el paso a un nuevo Office.