Si trabajas revisando logs de Windows, metadatos NTFS o trazas de una aplicación .NET, es probable que en algún momento te hayas encontrado un número de 17 o 18 dígitos que se parece a un epoch pero da una fecha sin sentido al convertirlo como Unix. Esta guía explica por qué ocurre, qué es realmente ese número, y cómo pasarlo a una fecha correcta.
Qué es un FILETIME de Windows
Respuesta corta Un FILETIME es un entero de 64 bits que cuenta intervalos de 100 nanosegundos desde el 1 de enero de 1601, 00:00:00 UTC — el epoch propio de Windows, muy distinto del epoch Unix.
Cuando exploras metadatos de archivos NTFS (fecha de creación, de último acceso, de última modificación), entradas del registro de Windows, o ciertos campos de eventos del Visor de sucesos, muchas veces el valor subyacente no es una fecha ya formateada, sino un FILETIME crudo: un número de 64 bits pensado para máquinas, no para humanos. Su punto de partida — 1601 — se eligió porque es el inicio del ciclo gregoriano de 400 años más cercano usado en cálculos internos de Microsoft, no por ninguna razón histórica relacionada con la informática.
FILETIME: intervalos de 100 ns desde el 1 de enero de 1601 UTC. Ejemplo ilustrativo: un FILETIME de 133650000000000000 correspondería aproximadamente al año 2024 (cifra solo de referencia, no verificada como valor real de producción).
Ticks de DateTime en .NET: un epoch distinto todavía
Respuesta corta DateTime.Ticks en .NET también usa intervalos de 100 ns, pero cuenta desde el 1 de enero del año 1 — no desde 1601 como FILETIME ni desde 1970 como Unix.
Si trabajas con C# o Visual Basic .NET, es habitual serializar una fecha como DateTime.Ticks — por ejemplo, al guardar una marca temporal en una cabecera HTTP personalizada, en una cola de mensajes, o en un campo de auditoría de base de datos. Numéricamente estos «ticks» comparten unidad con FILETIME (100 nanosegundos), pero no comparten el mismo punto de partida, así que un mismo instante se representa con dos números distintos según el sistema que lo generó.
Ejemplo (ilustrativo, no verificado): la diferencia constante entre el «año 1» de .NET y el «1601» de FILETIME equivale a 504.911.232.000.000.000 unidades de 100 ns — un desfase fijo que en teoría permite pasar de un sistema al otro con una simple resta o suma.
Por qué pegar ese número en un convertidor epoch da un resultado absurdo
Respuesta corta Un convertidor epoch Unix interpreta el número como segundos/milisegundos desde 1970; si en realidad es FILETIME o ticks de .NET, la escala y el punto de partida no coinciden y el resultado sale disparado a una fecha sin sentido.
Un epoch Unix en segundos ronda hoy los 10 dígitos, y en milisegundos unos 13. Un valor FILETIME o de ticks .NET correspondiente a una fecha reciente, en cambio, tiene típicamente 17-18 dígitos, porque la unidad (100 ns) es mucho más fina que el milisegundo. Si tomas ese número de 17-18 dígitos y lo interpretas como si fueran milisegundos o incluso nanosegundos Unix, el cálculo aterriza en una fecha absurdamente lejana — a menudo miles de años en el futuro o el pasado — porque además del problema de escala, el punto de partida (1601 o año 1, frente a 1970) introduce un desfase enorme.
Un escenario habitual: estás depurando un problema de auditoría en una aplicación .NET y encuentras en un log el valor 638500000000000000 como «fecha de evento». Pegarlo directamente en un convertidor epoch Unix normal, esperando segundos o milisegundos, no dará ningún resultado coherente — necesitas primero identificar que es un valor de ticks .NET, y aplicar la conversión correcta.
Cómo convertirlo a mano hoy
Respuesta corta Resta el desfase fijo entre el epoch de origen (1601 o año 1) y 1970, divide por 10.000.000 para pasar de intervalos de 100 ns a segundos, y el resultado es un epoch Unix normal que ya puedes pegar en el convertidor.
Mientras no exista una mini-herramienta dedicada, el camino manual es el siguiente, de forma conceptual:
- Si el valor es un FILETIME (desde 1601): resta 116.444.736.000.000.000 (el número de intervalos de 100 ns entre 1601 y 1970), y luego divide el resultado entre 10.000.000 para obtener segundos Unix.
- Si el valor son ticks .NET (desde el año 1): resta 621.355.968.000.000.000 (intervalos de 100 ns entre el año 1 y 1970), y divide igualmente entre 10.000.000 para obtener segundos Unix.
- El resultado — ya en segundos Unix estándar — se puede pegar en la pestaña «Epoch → Fecha» del convertidor de timestamp Unix de ToolPico para obtener la fecha-hora legible, en UTC, local o una zona personalizada.
Las cifras de desfase anteriores son valores de referencia habituales para este tipo de conversión; verifica siempre con tu propia documentación o entorno antes de usarlas en un sistema crítico.
Una mini-herramienta futura para esto
Sería razonable añadir en el futuro un mini-conversor dedicado FILETIME/ticks .NET ↔ epoch directamente en la página del convertidor, similar a las mini-herramientas ya existentes para fecha serial de Excel o para IDs Snowflake — de forma que quien depura un log de Windows o .NET no tenga que hacer la resta y división a mano. Por ahora, esta guía sirve como referencia manual mientras esa función no esté disponible.
¿Necesitas convertir un epoch Unix estándar ahora mismo?
Segundos, milisegundos, UTC o zona local — todo en tu navegador, sin enviar datos a ningún servidor.
Probar la herramienta →
Preguntas frecuentes
¿Qué es un FILETIME de Windows?
Un FILETIME es el formato de fecha-hora nativo de Windows: un entero de 64 bits que cuenta intervalos de 100 nanosegundos desde el 1 de enero de 1601, 00:00:00 UTC. Se usa internamente en la API de Windows, en el registro, en metadatos de archivos NTFS y en muchos logs del sistema operativo. Es un epoch completamente distinto al Unix, tanto en la unidad (100 ns frente a segundos) como en el punto de partida (1601 frente a 1970).
¿Qué son los «ticks» de DateTime en .NET?
En .NET, DateTime.Ticks también cuenta intervalos de 100 nanosegundos, pero desde el 1 de enero del año 1 (calendario gregoriano proléptico), no desde 1601 ni desde 1970. Por eso un valor de ticks de .NET y un FILETIME de Windows comparten la misma unidad (100 ns) pero tienen un desfase fijo entre sí, y ambos son numéricamente muy distintos de un epoch Unix en segundos o milisegundos.
¿Por qué un número de 17 o 18 dígitos en un log no es un epoch Unix?
Un epoch Unix en segundos tiene unos 10 dígitos hoy en día, y en milisegundos unos 13; para llegar a 17-18 dígitos con una fecha razonable haría falta una precisión de nanosegundos poco habitual en logs de Windows. Si ves un entero de esa longitud en un log de IIS, Active Directory, NTFS o en una traza de .NET, lo más probable es que sea un FILETIME o un valor de ticks, no un epoch Unix — y aplicar la fórmula epoch a ese número da una fecha absurda, normalmente muy alejada en el pasado o el futuro.
¿Cómo distingo un FILETIME de Windows de unos ticks de .NET a simple vista?
Numéricamente son muy parecidos porque comparten unidad (100 ns), pero el punto de partida difiere: un FILETIME cuenta desde 1601 y un valor DateTime.Ticks cuenta desde el año 1, por lo que un mismo instante da como ticks de .NET un número mayor que como FILETIME, con una diferencia fija de 504.911.232.000.000.000 unidades de 100 ns (equivalente a los años transcurridos entre el año 1 y 1601, incluyendo bisiestos). Sin conocer el origen del dato (¿viene de una API Win32 o de código C#?) no siempre se puede saber con certeza cuál de los dos es; el contexto del sistema que generó el valor suele ser la pista más fiable.
¿Se puede convertir FILETIME o ticks de .NET con esta herramienta hoy?
Actualmente el convertidor de ToolPico está centrado en el epoch Unix (segundos, milisegundos, microsegundos y nanosegundos) y en formatos derivados como fecha serial de Excel, Snowflake, UUID v1 o ULID. Un mini-conversor específico para FILETIME/ticks de .NET ↔ epoch es una mejora que consideramos para el futuro; mientras tanto, la conversión manual descrita en esta guía permite obtener el resultado con una calculadora normal.
Nota: este artículo tiene fines informativos y educativos; los valores numéricos de ejemplo son ilustrativos y no deben tomarse como referencia exacta para sistemas en producción. Verifica siempre los resultados críticos con tu propia fuente de datos.