Timestamps Unix: qué significa el número y cómo leerlo

Un timestamp Unix es un solo número: la cuenta de segundos transcurridos desde las 00:00:00 UTC del 1 de enero de 1970. 1789776000 es el 19 de septiembre de 2026 a medianoche UTC. Esa es toda la definición. No lleva zona horaria dentro, ni calendario, ni formato: solo una cuenta corrida desde un instante fijo con el que todas las máquinas están de acuerdo.

Ese instante fijo se llama época Unix (epoch). Los valores anteriores son negativos, los posteriores suben de uno en uno cada segundo y, como todo el asunto es aritmética y no fechas, dos timestamps se pueden comparar, ordenar y restar sin que nadie tenga que saber cuántos días tiene febrero.

¿Por qué contar segundos en lugar de guardar una fecha?

Porque los enteros se portan bien y las fechas no. Los meses van de 28 a 31 días. Los años bisiestos ocurren cada cuatro años, salvo cada cien, salvo cada cuatrocientos. Los relojes se adelantan y se atrasan dos veces al año en algunos países y nunca en otros, y los países cambian de opinión sobre a qué grupo pertenecen. Las fechas escritas como texto son todavía peores: 03/04/2026 son dos días distintos según quién lo haya escrito.

Un timestamp esquiva todo eso. "Cuál fue primero" es una comparación. "Cuánto tiempo pasó entre los dos" es una resta. Ordenar un log es ordenar números. El valor cabe en 8 bytes, sobrevive a que lo escribas en un archivo o en una URL sin escaparlo, y cualquier cosa capaz de leer un entero puede leerlo.

El precio es que una persona no puede leerlo, y que un timestamp solo puede significar un instante. No puede expresar "las 9 de la mañana, sea lo que sea que eso signifique en Madrid en marzo del año que viene", que es algo real que los calendarios necesitan guardar y una razón real por la que a veces un timestamp es la herramienta equivocada.

Cómo leer uno de cabeza

No vas a sacar el minuto, pero con dos divisiones obtienes el año y el mes aproximado.

1. Divide entre 86.400, la cantidad de segundos que tiene un día. Eso te da los días transcurridos desde el 1 de enero de 1970. El resto son los segundos pasada la medianoche UTC.
2. Divide los días entre 365,25 para obtener los años desde 1970. Suma eso a 1970 para el año; la fracción que sobra, multiplicada por 12, es aproximadamente el mes.

Probemos con 1789776000. Dividido entre 86.400 da exactamente 20.715 días, sin nada de resto, así que cae justo en la medianoche UTC. 20.715 ÷ 365,25 da 56,7, así que 1970 + 56 da 2026, y 0,7 × 12 lo sitúa alrededor del noveno mes. La respuesta real es la medianoche UTC del 19 de septiembre de 2026, lo suficientemente cerca como para revisar de reojo una línea de log.

Vale la pena memorizar unos cuantos puntos de referencia, porque te dejan ubicar cualquier número al instante:

Cuando importa el minuto exacto, hazlo bien. Pega el número en el conversor de timestamps y te dice qué unidad dedujo a partir de la cantidad de dígitos, y después te da la hora local, la UTC, las dos formas ISO 8601 y a qué distancia de ahora está ese instante. Funciona dentro de la página, así que el valor no va a ninguna parte.

¿Segundos, milisegundos u otra cosa?

De aquí sale la mayoría de los bugs con timestamps. Las herramientas Unix, la mayoría de las bases de datos SQL y muchísimas APIs cuentan segundos enteros. JavaScript, Java y todo lo que desciende de ellos cuentan milisegundos. Go y algunos sistemas de tracing cuentan nanosegundos. A todos la documentación los llama "el timestamp".

Cuenta los dígitos. Para cualquier fecha cercana al presente, la longitud lo delata:

Esas longitudes son estables durante toda una vida. Un timestamp en segundos tiene 10 dígitos desde el 9 de septiembre de 2001 y los seguirá teniendo hasta 2286.

Las dos formas de equivocarse no se ven igual de fácil. Si le pasas milisegundos a algo que espera segundos, terminas casi 57.000 años en el futuro, y eso alguien lo nota en menos de una hora. Si le pasas segundos a algo que espera milisegundos, terminas en enero de 1970: new Date(1789776000) en JavaScript es el 21 de enero de 1970, no septiembre de 2026. Esa es una respuesta equivocada con pinta de plausible, que se va calladita al principio de todas las listas ordenadas y nunca lanza un error. Si una fecha de tu app dice 1970, te estás equivocando por un factor de 1000.

¿Un timestamp Unix tiene zona horaria?

No, aunque hay muchísimo código escrito como si la tuviera. El número está definido respecto a UTC, pero no lleva una zona encima como sí la lleva una fecha formateada. Nombra un instante. La zona se aplica cuando lo muestras, y por eso el mismo timestamp marca las 09:00 en Londres y las 17:00 en Tokio y las dos pantallas tienen razón.

El daño se hace en la otra dirección. Alguien lee los dígitos de un reloj de pared local, los convierte sin indicar el desfase y guarda el resultado. El instante guardado queda mal por ese desfase, y el tamaño del error cambia dos veces al año cuando se mueve el horario de verano. Si el valor vino del calendario de una persona y no del reloj de una máquina, guarda al lado el nombre de la zona — Europe/Madrid, no +01:00. Un desfase es un dato sobre una fecha concreta; una zona es una regla.

Dónde te vas a topar con uno

• Tokens. Los campos exp, iat y nbf de un JWT son segundos Unix, y por eso lo que hay dentro de un JWT parece un muro de números de diez dígitos.
• La shell. date +%s imprime el timestamp actual en segundos en Linux y macOS.
• Bases de datos. FROM_UNIXTIME() de MySQL y to_timestamp() de PostgreSQL reciben segundos.
• Hojas de cálculo. Excel y Google Sheets cuentan días desde otro cero, así que la conversión es =A1/86400+25569, con formato de fecha. El resultado está en UTC.
• Identificadores. El UUID versión 7 lleva un timestamp de 48 bits en milisegundos en sus primeros seis bytes, que es justamente su razón de ser: los IDs se ordenan por fecha de creación.

Qué se rompe: 2038, fechas negativas y segundos intercalares

2038. Un contador de 32 bits con signo llega a su tope en 2.147.483.647 segundos, que son las 03:14:07 UTC del 19 de enero de 2038. Un segundo más tarde da la vuelta a un número negativo y la fecha pasa a leerse como diciembre de 1901. Tu computadora está bien — el tiempo de 64 bits cubre unos 292.000 millones de años en cada dirección — pero todavía quedan valores de 32 bits en firmware embebido, en formatos de archivo viejos y en columnas de bases de datos. El tipo TIMESTAMP de MySQL está limitado exactamente a ese instante de 2038 mientras que DATETIME no lo está, así que la fecha de vencimiento de una hipoteca o la caducidad de un certificado guardadas en la columna equivocada ya están rotas hoy.

Valores negativos. Una fecha de nacimiento de 1965 es un timestamp negativo perfectamente válido, y aun así mucho software lo rechaza igual: columnas sin signo, algunas bibliotecas de fechas y muchas APIs rechazan cualquier cosa por debajo de cero. Prueba con fechas anteriores a 1970 en vez de dar por sentado que funcionan.

Segundos intercalares. POSIX define cada día como exactamente 86.400 segundos, así que los 27 segundos intercalares insertados en el tiempo civil entre 1972 y el último, el 31 de diciembre de 2016, sencillamente no aparecen en la cuenta. La ventaja es que convertir un timestamp en una fecha es aritmética sin tabla de consulta. El costo es que un timestamp Unix no puede nombrar un segundo intercalar en absoluto, y distintos sistemas no se ponen de acuerdo sobre qué pasa durante uno.

Precisión. Un timestamp en segundos no puede distinguir dos eventos ocurridos en el mismo segundo. Si estás ordenando eventos, eso importa, y es la razón habitual para recurrir a los milisegundos.

Cuándo un timestamp es la respuesta equivocada

Usa uno para cualquier cosa que ocurrió: líneas de log, campos de fecha de creación, caducidad de tokens, timestamps de caché. No uses uno para una fecha sin hora — un cumpleaños, la fecha de una factura, un feriado. Guardar "14 de julio" como timestamp te obliga a elegir una medianoche en alguna zona, y va a ser el día equivocado para alguien. Ahí el tipo correcto es un string YYYY-MM-DD.

Lo mismo pasa con las duraciones. Restar dos timestamps te da segundos, y convertir segundos en "dos meses y cuatro días" requiere reglas de calendario que un timestamp tiró a la basura a propósito. Para ese tipo de pregunta una calculadora de diferencia entre fechas es el camino más corto, y contar los días entre dos fechas explica por qué la respuesta depende de qué extremo incluyas.

Última actualización 19 de septiembre de 2026