AZ Tools

Conversor de épocas (Unix, FILETIME, Excel)

Tiempo

Diferentes sistemas operativos y apps miden el tiempo como 'segundos (o alguna unidad) desde algún punto cero elegido' — pero cada uno eligió diferente. Unix tomó 1970-01-01 UTC. NTP tomó 1900-01-01 UTC. Windows NT tomó 1601-01-01 UTC y cuenta en intervalos de 100 nanosegundos (FILETIME). Los ticks de .NET DateTime cuentan intervalos de 100 ns desde 0001-01-01. El Mac OS clásico HFS+ usó 1904-01-01 en segundos. Cocoa CFAbsoluteTime de Apple usa 2001-01-01 en segundos. Excel para Windows cuenta días desde 1899-12-30 (porque Lotus 1-2-3 trató 1900 como año bisiesto por error y Excel heredó el bug); Excel para Mac cuenta desde 1904-01-01. Luego están los formatos legibles: ISO 8601 ('2026-06-05T00:00:00.000Z') y RFC 2822 ('Fri, 05 Jun 2026 00:00:00 GMT'). Cuando un BIGINT de SQL Server, una entrada del registro de eventos de Windows y un CSV de Numbers describen todos el mismo momento, necesitas traducir entre ellos. Esta herramienta lo hace en un solo paso — elige un formato a la izquierda, pega el valor y todos los demás se renderizan al instante con el desfase de época y unidad correctos. Se usa aritmética BigInt para FILETIME y ticks .NET para que la precisión sobreviva incluso en fechas lejanas que desbordarían el flotante de 53 bits de JavaScript.

Momentos de referencia
Todos los formatos
ISO 8601
Cadena ISO 8601 de fecha-hora en UTC
2026-06-10T04:05:15.049Z
RFC 2822
Cadena RFC 2822 / HTTP date en GMT
Wed, 10 Jun 2026 04:05:15 GMT
Unix (segundos)
época 1970-01-01 UTC · segundos
1781064315.049
Unix / JS (ms)
época 1970-01-01 UTC · milisegundos
1781064315049
NTP (segundos)
época 1900-01-01 UTC · segundos
3990053115.049
Windows FILETIME
época 1601-01-01 UTC · intervalos 100 ns
134255379150490000
.NET Ticks
época 0001-01-01 UTC · intervalos 100 ns
639166611150490000
Mac HFS+ (segundos)
época 1904-01-01 UTC · segundos
3863909115.049
Apple Cocoa
época 2001-01-01 UTC · segundos (CFAbsoluteTime)
802757115.049
Serial Excel 1900
época 1899-12-30 · fracción de día (compat bug Lotus)
46183.1703131
Serial Excel 1904
época 1904-01-01 · fracción de día (Mac Excel)
44721.1703131
Detalles de conversión

Valor canónico interno: milisegundos JS desde 1970-01-01 UTC (flotante 53 bits, válido para ~±285 614 años desde 1970). FILETIME y ticks .NET usan aritmética BigInt para preservar precisión entera exacta. Excel 1900 usa desfase 25569 (de 1899-12-30 a 1970-01-01) — correcto para todas las fechas desde 1900-03-01 en adelante y descarta silenciosamente el 1900-02-29 fantasma de Lotus. Las salidas ISO 8601 y RFC 2822 siempre en UTC/GMT.

Cómo usar

  1. Elige un formato fuente en el desplegable (por defecto: ISO 8601 en ahora).
  2. Pega o escribe el valor en ese formato — las 11 representaciones se actualizan al instante.
  3. Cambia el formato para convertir: el valor mostrado vuelve a llenar la caja en el nuevo formato.
  4. Usa un preajuste para sembrar momentos de referencia: ahora, época Unix (1970), Y2K, Y2038 o el rollover NTP (2036-02-07).
  5. Pulsa el botón de copiar de cualquier fila para copiar esa representación.

Preguntas frecuentes

¿Por qué el serial Excel 1900 empieza en 1899-12-30 y no en 1900-01-01?
Lotus 1-2-3 trató 1900 como bisiesto por error (no lo es — 1900 ÷ 100 = 19 con resto 0 pero 1900 ÷ 400 ≠ entero, así la regla gregoriana lo excluye). Cuando Microsoft construyó Excel copió el bug de Lotus por compatibilidad de hojas, lo que significa que Excel tiene un 29 de febrero de 1900 fantasma. Para que el desfase funcione limpio en todas las fechas tras 1900-03-01 usamos 25569 (días de 1899-12-30 a 1970-01-01), que da resultados correctos para toda fecha real. Las fechas anteriores a 1900-03-01 en Excel quedan desfasadas un día, pero son rarísimas en la práctica.
¿Por qué usar BigInt para FILETIME y .NET Ticks?
FILETIME cuenta intervalos de 100 ns desde 1601-01-01 UTC. Para un momento alrededor del año 2100 son ~1.6 × 10¹⁷ — muy por encima de Number.MAX_SAFE_INTEGER (~9 × 10¹⁵). Los dígitos bajos se desvían silenciosamente si lo guardas como Number normal de JavaScript. Lo mismo para ticks .NET (~6.6 × 10¹⁷ hacia 2100). BigInt es el tipo entero de precisión arbitraria de JS y conserva cada dígito exacto, así que pasar un FILETIME por esta herramienta devuelve exactamente los mismos dígitos.
¿Qué es el problema Y2038 y afecta a tu salida Unix?
Muchos programas C heredados guardan el tiempo Unix como entero con signo de 32 bits, que desborda en 2³¹ − 1 segundos tras 1970 = 03:14:07 UTC del 2038-01-19. Esta herramienta guarda el tiempo como milisegundos JS (flotante de 64 bits, válido para ±285 614 años alrededor de 1970), así que Y2038 no es problema aquí. Exponemos Y2038 como preajuste para ver cómo lo representan los formatos. NTP tiene su propio rollover en 2036 porque el contador de 32 bits reinicia; también es preajuste.
¿Por qué Excel 1900 y Excel 1904 a la vez?
Excel para Windows usa 1900 como base; Excel para Mac (y Numbers, hasta hace poco) usa 1904. Una hoja enviada por email entre un analista Windows y uno Mac se verá correcta en cada app, pero se desplazará silenciosamente ~4 años si los seriales subyacentes se copian crudos. Ambos formatos se exponen para detectar o convertir entre ellos.

Herramientas relacionadas