Las marcas de tiempo Unix explicadas: segundos o milisegundos, zonas horarias y el problema del año 2038

Qué es una marca de tiempo Unix

Una marca de tiempo Unix (tiempo Unix, tiempo epoch) es un único entero que cuenta los segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970, el epoch de Unix. 0 es 1970-01-01 00:00:00 UTC y 1700000000 es 2023-11-14 22:13:20 UTC.

Representar un instante con un solo número tiene muchas ventajas. La diferencia entre dos instantes es una simple resta, ordenar y comparar es trivial, y el mismo instante tiene el mismo valor en todas partes, sin importar la zona horaria ni el formato de fecha.

0           → 1970-01-01 00:00:00 UTC
1700000000  → 2023-11-14 22:13:20 UTC
1735689600  → 2025-01-01 00:00:00 UTC
2147483647  → 2038-01-19 03:14:07 UTC

¿10 dígitos o 13? ¿Segundos o milisegundos?

Una marca de tiempo actual en segundos tiene 10 dígitos. Sin embargo, Date.now() de JavaScript y System.currentTimeMillis() de Java devuelven milisegundos: 13 dígitos. Confundirlos produce fechas como el 21 de enero de 1970 o fechas cincuenta mil años en el futuro.

Cuenta los dígitos: 10 son segundos, 13 milisegundos y 16 microsegundos. Si una API no documenta la unidad, compruébala, y multiplica o divide por 1.000 al convertir.

Una marca de tiempo no tiene zona horaria

Lo más importante es que una marca de tiempo no tiene zona horaria. 1700000000 es el mismo instante en Madrid y en Nueva York. La zona horaria solo se aplica al mostrar el número como una fecha legible: el mismo valor son las 22:13 en UTC y las 23:13 en Madrid en invierno (UTC+1).

El clásico error de «una hora de diferencia» surge al romper esta regla: guardar en UTC pero mostrarlo como si fuera hora local, o guardar una hora local sin desfase y leerla como UTC. Guarda y transmite en UTC (o como marcas de tiempo); muestra en la zona horaria del usuario.

Las trampas del horario de verano

España, como la mayor parte de Europa y Estados Unidos, adelanta el reloj en primavera y lo atrasa en otoño, pero no en las mismas fechas. Por eso «Nueva York va seis horas por detrás de Madrid» solo es cierto parte del año: durante unas semanas en marzo y entre octubre y noviembre la diferencia es de cinco horas.

Usa nombres de zona IANA como America/New_York o Europe/Madrid en lugar de desfases fijos como -05:00, para que los cambios se gestionen automáticamente. Al programar reuniones con equipos de otros países o configurar tareas, comprueba el desfase real de esa fecha con una calculadora de zonas horarias.

El problema del año 2038

Guardada como entero de 32 bits con signo, una marca de tiempo llega como máximo a 2.147.483.647, que corresponde a las 03:14:07 UTC del 19 de enero de 2038. Un segundo después el valor se desborda a un número negativo y salta a 1901. Es el problema del año 2038.

Los sistemas operativos y lenguajes modernos usan sobre todo tiempo de 64 bits, pero los valores de 32 bits sobreviven en dispositivos embebidos antiguos, columnas INT de bases de datos y formatos de archivo. Los sistemas que manejan fechas lejanas —certificados de larga duración o préstamos a 30 años— pueden toparse ya con el límite, así que en diseños nuevos usa enteros de 64 bits o tipos de fecha adecuados.

Segundos intercalares y precisión

El tiempo Unix considera que cada día dura exactamente 86.400 segundos e ignora los segundos intercalares. Por eso puede diferir muy ligeramente del tiempo transcurrido astronómicamente exacto, algo que las aplicaciones normales pueden ignorar sin problema. La Conferencia General de Pesas y Medidas ha decidido suprimir los segundos intercalares antes de 2035.

Pega un número en el conversor de marcas de tiempo de AIBIZAP: detecta automáticamente si son segundos o milisegundos y muestra la fecha en UTC y en la zona elegida. Usa la calculadora de zonas horarias para comparar horas locales y el generador cron para tareas que se repiten a horas fijas.