Una marca de tiempo Unix es un solo número: cuántos segundos han pasado desde la medianoche UTC del 1 de enero de 1970. Ese es todo el diseño, y su economía explica que esté en todas partes: registros, bases de datos, JWT y APIs. También explica por qué hace falta una herramienta, porque un número como 1752537600 no le dice absolutamente nada a un humano.
Segundos o milisegundos: el factor 1000
El tiempo Unix cuenta segundos. JavaScript cuenta milisegundos: Date.now() devuelve un número mil veces mayor, y lo mismo hace cualquier constructor Date de JavaScript. Este desajuste es responsable de más marcas de tiempo rotas que todo lo demás junto.
El síntoma es inconfundible una vez que lo conoces. Pasa un valor en segundos a algo que espera milisegundos y aterrizas en enero de 1970: todo el arco del tiempo Unix hasta ahora se reduce a tres semanas. Pasa milisegundos donde se esperan segundos y obtienes una fecha a cincuenta mil años vista. Ninguno da error. Ambos se representan tan contentos como una fecha, y eso es lo que hace que el fallo sobreviva a la revisión de código.
Una comprobación rápida: una marca de tiempo actual en segundos tiene diez dígitos, y en milisegundos trece. Si estás mirando un número y dudas, cuenta los dígitos antes de dividir.
Una marca de tiempo no tiene zona horaria
Vale la pena interiorizarlo, porque disuelve la mayor parte de la confusión sobre husos. Una marca de tiempo Unix es un instante: el mismo momento para cualquiera que esté vivo. No está en UTC más de lo que está en hora de Tokio; simplemente es. Los husos solo entran cuando representas ese instante como fecha legible, y eso es una decisión de presentación, no una propiedad del dato.
Así que "convertir esta marca de tiempo a UTC" no es una conversión en absoluto: es una elección de formato. El selector de huso de aquí cambia cómo se escribe el mismo instante subyacente, no lo que significa. También es la razón por la que guardar marcas de tiempo en vez de cadenas de fecha local ahorra tanto dolor: un instante es inequívoco y "2025-10-26 02:30" no.
El problema del año 2038 es real y ya está mordiendo
Durante décadas los sistemas Unix guardaron el tiempo en un entero de 32 bits con signo. Ese se agota en 2147483647 segundos, es decir, las 03:14:07 UTC del 19 de enero de 2038. Un segundo después el valor se desborda, pasa a negativo, y la fecha se convierte en el 13 de diciembre de 1901.
Suena a problema lejano y no lo es. Cualquier sistema que calcule una fecha a más de unos pocos años ya cruza la línea: una hipoteca a treinta años, la caducidad de un certificado, una proyección de pensión. Errores de este tipo se encontraban en producción mucho antes de 2020. La mayoría de las plataformas modernas han pasado al tiempo de 64 bits —lo que empuja el límite más allá de la vida esperada del Sol— pero los dispositivos embebidos, los formatos de archivo antiguos y algunas columnas de base de datos no. Si hoy guardas una marca de tiempo en una columna de 32 bits, eso es un fallo con fecha de vencimiento.
El tiempo Unix ignora deliberadamente los segundos intercalares
He aquí un dato que sorprende incluso a desarrolladores con experiencia: una marca de tiempo Unix no es un recuento verdadero de segundos transcurridos. Desde 1972 el mundo ha insertado 27 segundos intercalares para mantener los relojes alineados con la rotación de la Tierra, y el tiempo Unix se los salta todos. Define cada día como exactamente 86400 segundos, tuviera ese día 86400 segundos o no.
El intercambio es deliberado. Hace trivial la aritmética —cualquier fecha se convierte en marca de tiempo con una simple división— a costa de que el recuento sea ligeramente erróneo en sentido absoluto. También significa que el segundo intercalar real 23:59:60 sencillamente no es expresable: JavaScript lo rechaza de plano, y Date.parse("2016-12-31T23:59:60Z") devuelve NaN aunque ese segundo existió de verdad. Si necesitas tiempo transcurrido real a través de segundos intercalares, el tiempo Unix es el instrumento equivocado; para el 99,99% restante del software este compromiso es exactamente el correcto.
Horas locales ambiguas e imposibles
Las marcas de tiempo son limpias; las horas locales no. Dos veces al año, el horario de verano hace que la hora del reloj de pared se porte mal. Cuando en Roma los relojes se atrasan el último domingo de octubre, las 02:30 ocurren dos veces: una hora local "2025-10-26 02:30" corresponde a dos instantes distintos y nada en la cadena te dice cuál. Cuando los relojes se adelantan en marzo, las 02:30 no existen en absoluto.
Por eso convertir una fecha local en marca de tiempo pierde información de verdad, de un modo en que lo contrario nunca lo hace. Si guardas citas, entradas de registro, cualquier cosa donde importe el instante exacto, guarda la marca de tiempo y representa la hora local a la salida, no al revés.
Preguntas frecuentes
¿Se envían mis datos a un servidor?
No. Esta herramienta está marcada como "client": la conversión es aritmética y formato hechos en la pestaña de tu navegador, con su propia base de datos de husos horarios. No se transmite nada.
Mi marca de tiempo aparece como 1970. ¿Qué ha fallado?
Algo ha leído segundos como milisegundos. Multiplica por 1000 y la fecha tendrá sentido. Suele significar que un valor correcto en la base de datos se pasó directamente a un constructor Date de JavaScript sin conversión: Date espera milisegundos y no te avisa.
¿Puede una marca de tiempo ser negativa?
Sí: solo significa antes de 1970. Una marca de tiempo de -1 es el 31 de diciembre de 1969 a las 23:59:59 UTC. La mayoría del software lo maneja bien, pero no todo: los campos de fecha de nacimiento para quien nació antes de 1970 han sido históricamente una mina de errores en sistemas cuyos autores dieron por hecho que las marcas de tiempo eran siempre positivas.
¿Por qué la misma marca de tiempo muestra otra hora en la pantalla de mi colega?
Porque estáis en husos distintos, y ese es el comportamiento correcto, no un fallo. El instante es idéntico; solo cambia cómo se representa. Si necesitas que todos lean la misma hora de reloj —una ventana de mantenimiento programada, por ejemplo— indica el huso explícitamente al lado, o usa UTC y dilo.
¿Debo guardar las fechas como marcas de tiempo o como cadenas?
Guarda el instante, ya sea como entero o como una columna de marca de tiempo con huso en condiciones: tu base de datos casi seguro tiene una, y manejará rangos y aritmética que un entero pelado no puede. Lo que hay que evitar es una cadena de fecha local sin huso: es ambigua dos veces al año en los cambios de horario, y no hay forma de recuperar después la información que falta.