Windows guarda las marcas de tiempo de tus archivos con una precisión brutal, pero el punto de partida que usa para contar resulta chocante a primera vista: el 1 de enero de 1601. No es un error de programación ni un resto arqueológico de MS-DOS. Es una decisión matemática deliberada que simplifica el cálculo de fechas y evita errores de redondeo con los años bisiestos. La cifra que ves en las propiedades de un archivo —creado, modificado, accedido— esconde un número entero de 64 bits que cuenta intervalos de 100 nanosegundos desde ese instante concreto. Entender ese mecanismo ayuda a comprender por qué NTFS funciona como funciona y por qué convertir fechas entre sistemas operativos a veces da dolores de cabeza.

El formato FILETIME, explicado sin rodeos

Microsoft documenta este formato como FILETIME: un valor de 64 bits que representa los intervalos de 100 nanosegundos transcurridos desde las 00:00 UTC del 1 de enero de 1601. Cada segundo se divide en 10 millones de esos intervalos, lo que otorga a Windows una resolución muy superior a la del segundo entero que usa Unix. El sistema no necesita traducir esa cifra a un formato legible hasta que una aplicación lo solicita; internamente, todo es aritmética con enteros. Esa elección de diseño reduce la carga de cálculo del núcleo y evita ambigüedades derivadas de husos horarios, porque NTFS almacena siempre la marca en UTC, independientemente de dónde esté físicamente la máquina.

Por qué 1601 y no cualquier otro año

La razón detrás del año elegido tiene que ver con los ciclos del calendario gregoriano. Ese calendario repite su estructura completa de años bisiestos cada 400 años, así que arrancar el contador en el inicio de un ciclo de ese tipo simplifica enormemente las operaciones de conversión entre segundos y fechas de calendario. Los ingenieros de Windows NT no eligieron 1601 por nostalgia histórica, sino porque situar el origen al principio de un ciclo de 400 años vuelve el cálculo de bisiestos una operación limpia y predecible. Esa misma fuente detalla que la diferencia exacta entre el 1 de enero de 1601 y el 1 de enero de 1970 —el epoch de Unix— es de 11.644.473.600 segundos, una cifra que aparece constantemente en las rutinas de conversión entre ambos sistemas.

Comparación directa con el epoch de Unix

Unix cuenta el tiempo desde el 1 de enero de 1970, casi cuatro siglos después del punto de partida elegido por Microsoft. Esa diferencia de arranque no es un capricho: ambos sistemas resuelven el mismo problema, pero con prioridades distintas. Unix prioriza un número pequeño y manejable de segundos desde una fecha reciente; Windows prioriza la precisión y la robustez matemática frente a los años bisiestos. Con 64 bits de resolución y una granularidad de 100 nanosegundos, FILETIME puede representar fechas durante más de 58.000 años sin desbordar el contador, un margen que deja obsoleto cualquier problema tipo «efecto 2038» que sí afecta a implementaciones de 32 bits en sistemas Unix. Convertir entre ambos formatos exige multiplicar el valor de Unix por 10.000.000 para pasar a intervalos de 100 nanosegundos y sumarle después el desfase de 11.644.473.600 segundos mencionado antes.

NTFS: el producto detrás del sistema de fechas

El auténtico protagonista de esta historia es NTFS, el sistema de archivos que Microsoft introdujo con Windows NT y que sigue siendo el estándar en cualquier instalación moderna de Windows. NTFS almacena las cuatro marcas de tiempo de cada archivo —creación, modificación, acceso y cambio de metadatos— directamente en formato UTC, lo que evita el problema clásico de FAT, donde las horas se guardaban en hora local y un archivo creado a las 15:00 en Madrid podía aparecer con una hora distinta al copiarlo a un equipo en otro huso horario. Esa decisión de diseño no es cosmética: al fijar el origen del contador en 1601 y trabajar siempre en UTC, NTFS garantiza que dos máquinas distintas, en distintos países, interpreten exactamente la misma marca de tiempo sin ambigüedad. En nuestras pruebas habituales con NAS y servidores domésticos que combinan volúmenes NTFS y Samba, esta coherencia horaria resulta clave para evitar desincronizaciones al sincronizar copias de seguridad entre distintos sistemas operativos.

Los límites prácticos y las curiosidades del formato

Como todo valor con signo positivo, FILETIME tiene un límite inferior: no puede representar fechas anteriores al 1 de enero de 1601, porque el contador simplemente no admite números negativos. Este detalle técnico tiene consecuencias reales en herramientas de desarrollo. El propio código fuente de GLib, la biblioteca base del entorno GNOME, documenta que las funciones de formato de fecha de Windows fallan si se les pide representar una fecha anterior a esa frontera. Es un caso interesante de cómo una decisión de diseño tomada en los años noventa sigue condicionando el comportamiento de software multiplataforma décadas después. También existen valores especiales dentro de este esquema: en Active Directory, un valor de cero en un campo de tiempo FILETIME indica que ese dato nunca se ha inicializado, y el valor máximo representable en un entero de 64 bits con signo se usa como marcador de «nunca expira» en atributos como la caducidad de contraseñas.

Implicaciones para quien administra sistemas

Para cualquiera que trabaje con scripts de automatización, análisis forense o simplemente scripts de PowerShell que manipulan metadatos de archivos, entender FILETIME no es un ejercicio académico. Muchas API de Windows exponen directamente el valor de 64 bits en bruto, y traducirlo a una fecha legible exige aplicar la fórmula de conversión correcta. Un error habitual consiste en tratar ese número como si fueran segundos desde 1970, lo que produce fechas absurdas desplazadas casi 400 años. La forma correcta de operar pasa por dividir el valor entre 10.000.000 para obtener segundos y restar después el desfase de 11.644.473.600 segundos si se quiere llegar al epoch Unix. Esta aritmética, aunque sencilla sobre el papel, es una fuente constante de bugs sutiles en herramientas que procesan logs, metadatos de sistemas de archivos o eventos de seguridad extraídos de un Visor de sucesos.

Reflexiones finales

Lo que a simple vista parece una anécdota curiosa —por qué Windows insiste en fechar tus archivos desde el reinado de Isabel I de Inglaterra— resulta ser una lección compacta de ingeniería de sistemas bien pensada. Elegir un epoch alineado con el inicio de un ciclo bisiesto de 400 años no es elegancia gratuita, es una optimización real que simplifica el cálculo de fechas durante décadas de evolución del sistema operativo. La próxima vez que abras las propiedades de un archivo y veas una fecha de creación de hace unos días, merece la pena recordar que, por debajo, hay un contador de 64 bits que lleva sumando intervalos de 100 nanosegundos desde hace más de cuatrocientos años, sin haberse acercado siquiera a su límite teórico. Ese tipo de decisiones invisibles son las que sostienen la fiabilidad de un sistema de archivos usado por miles de millones de dispositivos.