El tiempo Unix es la fontanería bajo casi cualquier timestamp que toques: el created_at de la base de datos, el expiry de un JWT, la hora de una línea de log, la fecha de modificación de un archivo, las cabeceras HTTP. Pese a ser ubicuo, tiene rarezas que sorprenden a desarrolladores cada año — segundos vs milisegundos, los trampas de zona horaria, el inminente desbordamiento de 2038. Esta guía explica qué es realmente y cómo trabajar con él de forma segura.

Qué es

El tiempo Unix es el recuento de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970, llamado epoch Unix. Todo instante del tiempo se convierte en un único entero — una recta numérica anclada en 1970 que se extiende hacia adelante (positivo) y, menos útil, hacia atrás (negativo). Hoy el tiempo Unix anda por los 1.780 millones y subiendo.

Por qué 1970

Unix se estaba desarrollando en Bell Labs cuando el equipo necesitó un punto cero para sus nuevas funciones de tiempo. Los candidatos obvios — un año históricamente significativo, un siglo redondo — traían equipaje. La elección pragmática fue una fecha redonda reciente: 1 de enero de 1970, 00:00:00 UTC. Nada especial pasó ese día. Su valor era estar suficientemente cerca de "ahora" para mantener los números pequeños y lo bastante lejos como para que los archivos existentes no necesitaran timestamps negativos.

Segundos o milisegundos

El tiempo Unix original es segundos. Todo sistema POSIX — Linux, macOS, bases de datos, time.time() de Python casteado a int — devuelve segundos. Pero JavaScript eligió milisegundos cuando se especificó Date.now() en 1995, y la mayoría de APIs modernas (Java, stdlib de Go, formatos ISO, bases modernas) le siguieron. Resultado: dos convenciones conviviendo. Un timestamp de 10 dígitos casi siempre es segundos; uno de 13 dígitos, milisegundos. Al montar una integración, comprueba en qué lado del corte está el otro sistema — los bugs de mezclar ambos son silenciosos y producen fechas con 53 años de diferencia.

Zonas horarias y qué representa realmente

El tiempo Unix es siempre UTC. No conoce zonas horarias. Cuando un log dice "creado 1712345678", es un punto exacto de tiempo global — convertirlo a texto legible es donde entra la zona horaria. De hecho es una virtud: tus servidores, usuarios y bases pueden renderizar el mismo instante en sus horas locales sin discrepar nunca sobre cuándo.

El problema Y2038

El 19 de enero de 2038 a las 03:14:07 UTC, un entero de 32 bits con signo que guarde segundos Unix desborda. El segundo siguiente salta a un número negativo, interpretado como 13 de diciembre de 1901. Cualquier sistema que aún guarde tiempo Unix en int32 verá fechas revueltas. Dispositivos embebidos, formatos binarios antiguos y programas C longevos son el riesgo principal — tu app web casi seguro va bien, porque todo lenguaje y base mainstream pasó a 64 bits hace años. Un timestamp Unix de 64 bits no desborda hasta dentro de ~292.000 millones de años.

Por qué sigue dominando

Cualquier otro formato de timestamp necesita zona horaria, sistema de calendario o parser de texto para tener sentido. El tiempo Unix es un solo número, interpretable sin contexto, ordenable sin parsear, compacto al almacenar, barato al comparar. Sus descendientes — ISO 8601 y RFC 3339 para mostrar, relojes monótonos para medir elapsed — cubren lo que él solo no. Pero para "qué instante en tiempo global fue esto", el epoch de 1970 ganó y es improbable que sea sustituido.