Convertidor de marcas de tiempo de Unix

Contar los dígitos

Lo único de verdad delicado al leer una marca de tiempo es averiguar su unidad, y eso lo decide la magnitud. En la práctica no hay ambigüedad, porque los rangos no se solapan para ninguna fecha con la que alguien esté trabajando de verdad.

Equivocarse supone fallar por un factor de mil, así que el resultado aterriza o bien a principios de los setenta o bien decenas de miles de años en el futuro. Salta a la vista cuando lo miras; es completamente invisible cuando es una columna más de una tabla de registros, que es donde muerde de verdad.

Qué cuenta en realidad el tiempo Unix

Segundos desde las 00:00:00 UTC del 1 de enero de 1970, dando por hecho que todos los días duran exactamente 86 400 segundos.

Ese supuesto es falso. Cada pocos años se insertan segundos intercalares para mantener el tiempo atómico alineado con la rotación de la Tierra, que se va frenando poco a poco. El tiempo Unix no los representa: los sistemas repiten un segundo, o lo reparten a lo largo de un día, para que la cuenta siga siendo uniforme.

La consecuencia es que el tiempo Unix no es una cuenta real de los segundos transcurridos desde 1970: se queda corto en unos veintisiete. Para programar tareas, registrar sucesos y calcular caducidades ese es exactamente el intercambio correcto, porque la aritmética uniforme importa más que la exactitud astronómica. Para cualquier cosa que mida duración real transcurrida, usa mejor un reloj monotónico: el reloj de pared también puede saltar hacia atrás cuando NTP lo corrige.

El problema de 2038

Un entero de 32 bits con signo llega hasta 2 147 483 647, que como marca de tiempo Unix son las 03:14:07 UTC del 19 de enero de 2038. Un segundo después se desborda a negativo y la fecha pasa a ser diciembre de 1901.

Todo lo moderno usa 64 bits y aguanta unos 292 000 millones de años. Lo que no es moderno: firmware empotrado, controladores industriales, algunos tipos de columna de bases de datos antiguas y código en C que aún da por hecho un time_t de 32 bits. Los sistemas con más riesgo son aquellos que nadie mira, que es lo que también hizo caro el efecto 2000.

Qué formato usar de verdad

ISO 8601 en UTC, para cualquier cosa que cruce la frontera entre sistemas o que vaya a leer una persona:

2026-08-27T14:30:00Z

No es ambiguo, se ordena correctamente como simple cadena de texto y se lee bien en un registro a las dos de la madrugada. La Z importa: sin ella, casi todos los analizadores suponen hora local, y te acabas de inventar un error que solo aparece para los usuarios de otros países.

Los segundos Unix están bien de puertas adentro: son lo que usan los claims exp e iat de un JWT, y comparar enteros sale barato. Su coste es que no hay quien los lea y que invitan a la confusión de unidades de más arriba.

Conviene evitar: cualquier formato con desfase pero sin identificador de zona (+01:00 no te dice si eso es BST o CET, lo cual importa para fechas futuras) y cualquier cosa del estilo 03/04/2026, que significa dos días distintos según a qué lado del Atlántico lo leas.

Guardar eventos futuros

Una sutileza que pilla a mucha gente. Para una reunión a las 09:00 del próximo marzo, guardar UTC está mal: si las reglas de husos horarios cambian de aquí a entonces —y los gobiernos las cambian—, la reunión se mueve. Los eventos locales futuros deberían guardarse como hora local más un identificador de zona (Europe/London) y convertirse al mostrarlos con las reglas vigentes en ese momento. Los eventos pasados son lo contrario: UTC, porque lo que ocurrió ya es fijo.

Relacionado

Los claims exp e iat de un JWT son segundos Unix: el descodificador de JWT te los convierte y señala la caducidad. Para programar en lugar de convertir, el analizador de cron muestra cuándo se dispara la próxima vez una programación.