Para qué sirve
Un timestamp Unix es un número entero: los segundos transcurridos desde la medianoche UTC del 1 de enero de 1970. Aparece en los logs, en los campos iat y exp de un JWT, en las respuestas de casi cualquier API, en las columnas de fecha de una base de datos y en las cabeceras HTTP. Es cómodo para una máquina —ordenar, restar y comparar fechas se reduce a aritmética de enteros— y completamente ilegible para una persona, que es justo el hueco que cubre esta herramienta.
El conversor funciona en las dos direcciones y deduce por sí mismo, contando dígitos, si el número está en segundos, milisegundos, microsegundos o nanosegundos. Cada resultado se muestra a la vez en UTC y en la zona horaria de tu equipo, con el día de la semana, la semana ISO y el día del año de cada una. No es un adorno: el error habitual con los timestamps no es la aritmética, sino dar por buena una hora sin comprobar en qué huso está expresada, y a las 23:30 de un domingo en Madrid en UTC ya es lunes.
Lo que no hace: no convierte entre dos husos horarios cualesquiera —solo entre UTC y el de tu navegador—, no interpreta cadenas de fecha escritas a mano, y no sabe nada de los segundos intercalares, porque el propio tiempo Unix los ignora por definición. Las fechas anteriores a 1582 se dan en calendario gregoriano proléptico, así que no coincidirán con las de un documento de la época escrito en calendario juliano.
Cómo se calcula
La conversión es una suma. Al valor de la época —el 1 de enero de 1970 a las 00:00:00 UTC— se le añaden tantas unidades de tiempo como indique el número, y ya está. Lo que hace que sea así de simple es que el tiempo Unix define el día como 86 400 segundos exactos y no cuenta los segundos intercalares: sin esa regla, convertir un timestamp exigiría consultar una tabla de correcciones que hay que actualizar cada pocos años.
La unidad se deduce del número de dígitos. Cada salto de unidad multiplica por mil, es decir, añade tres cifras: una fecha actual ocupa 10 dígitos en segundos, 13 en milisegundos, 16 en microsegundos y 19 en nanosegundos. Los tramos se reparten a mitad de camino entre unos y otros, con margen suficiente para que no fallen: 11 dígitos leídos como segundos llegan hasta el año 5138. Aun así puedes forzar la unidad desde el desplegable cuando el número sea ambiguo y sepas de dónde viene.
Toda la aritmética se hace con enteros de precisión arbitraria. Un timestamp en nanosegundos tiene 19 dígitos y el mayor entero exacto de JavaScript, Number.MAX_SAFE_INTEGER, solo llega a 16: interpretarlo como número decimal perdería precisión antes incluso de empezar. La fecha resultante, en cambio, solo tiene resolución de milisegundo, así que si introduces microsegundos o nanosegundos la herramienta te dice cuánta precisión se ha quedado por el camino.
instante = 1970-01-01T00:00:00Z + n × unidad- n
- el número entero del timestamp; negativo si es anterior a 1970
- unidad
- segundo, milisegundo, microsegundo o nanosegundo
La época no es una fecha especial en el calendario: es simplemente el cero de la cuenta.
1 s = 1 000 ms = 1 000 000 µs = 1 000 000 000 nsCada salto multiplica por mil y por tanto añade tres dígitos. Esa es la razón de que la unidad se pueda adivinar a ojo, contando cifras.
2³¹ − 1 = 2 147 483 647 s → 2038-01-19T03:14:07ZEl último instante que cabe en un entero de 32 bits con signo. Un segundo después, el contador se vuelve negativo y la fecha salta a diciembre de 1901.
Ejemplo resuelto
Un log escupe 1767225600 y hay que saber cuándo fue
- Marca de tiempo
- 1767225600
- Zona del equipo
- Europe/Madrid
- El número tiene 10 dígitos, así que son segundos: en milisegundos una fecha de estos años ocuparía 13.
- 1767225600 / 86 400 = 20 454 días justos. Como no hay resto, el instante cae exactamente a medianoche.
- 20 454 días desde el 1 de enero de 1970 son 56 años completos (56 × 365 = 20 440 días) más los 14 días que aportan los años bisiestos de 1972 a 2024. Se llega al 1 de enero de 2026.
- En UTC queda 2026-01-01T00:00:00Z. En Madrid, que en enero va una hora por delante, ese mismo instante es la 01:00 del 1 de enero.
- Ese día es jueves, el día 1 de los 365 del año y la primera semana ISO de 2026.
1767225600 = 2026-01-01T00:00:00Z, que en Europe/Madrid es el jueves 1 de enero de 2026 a la 01:00.
Cuántos dígitos tiene cada unidad
Contar cifras es el atajo más rápido para saber en qué unidad está un número, y funciona porque las cuatro unidades habituales van de mil en mil. Todas ganaron un dígito el mismo día, el 9 de septiembre de 2001 a las 01:46:40 UTC: ese instante es 10⁹ segundos, 10¹² milisegundos, 10¹⁵ microsegundos y 10¹⁸ nanosegundos, todo a la vez.
La regla tiene fecha de caducidad, aunque lejana: el 20 de noviembre de 2286 los segundos pasarán a 11 dígitos y las cuatro unidades sumarán otra cifra a la vez. Hasta entonces, si un número empieza por 17 y tiene 10 dígitos son segundos de mediados de esta década; con 13, milisegundos.
| Unidad | Dígitos hoy | El mismo instante | Dónde aparece |
|---|---|---|---|
| Segundos | 10 | 1767225600 | POSIX, date +%s, los campos iat y exp de un JWT |
| Milisegundos | 13 | 1767225600000 | Date.now() en JavaScript, System.currentTimeMillis() en Java |
| Microsegundos | 16 | 1767225600000000 | PostgreSQL, ClickHouse, las trazas de OpenTelemetry |
| Nanosegundos | 19 | 1767225600000000000 | time.UnixNano() en Go, time.time_ns() en Python, InfluxDB |
Fechas frontera que conviene tener a mano
La primera fila y la cuarta son los límites de un entero de 32 bits con signo, que es como se guardaba la hora en casi todos los sistemas hasta hace poco. Entre las dos caben algo más de 136 años, repartidos a los dos lados de 1970.
Ese rango sigue vivo en sitios muy concretos: el tipo TIMESTAMP de MySQL solo acepta de 1970-01-01 00:00:01 a 2038-01-19 03:14:07 —para fechas fuera de ahí hay que usar DATETIME—, y muchos protocolos y formatos binarios reservan exactamente 32 bits para el campo. Con 64 bits el problema desaparece por completo: el contador aguanta unos 292 000 millones de años.
| Instante (UTC) | Timestamp en segundos | Por qué importa |
|---|---|---|
| 1901-12-13 20:45:52 | −2147483648 | El mínimo de un entero de 32 bits con signo |
| 1970-01-01 00:00:00 | 0 | La época: el origen de la cuenta |
| 2001-09-09 01:46:40 | 1000000000 | El primer timestamp de 10 dígitos |
| 2038-01-19 03:14:07 | 2147483647 | El máximo de un entero de 32 bits con signo |
| 2286-11-20 17:46:40 | 10000000000 | El primer timestamp de 11 dígitos |
Preguntas frecuentes
¿Cómo sé si mi número está en segundos o en milisegundos?
Cuenta los dígitos. Para cualquier fecha de este siglo y hasta 2286, los segundos son 10 cifras y los milisegundos 13. Si al convertirlo te sale un año absurdo —el 57971, por ejemplo— casi seguro que has leído milisegundos como si fueran segundos: son mil veces más, y mil veces 56 años son 56 000 años. La herramienta te avisa cuando la fecha se va tan lejos.
¿Por qué el 1 de enero de 1970 y no otra fecha?
Por comodidad de los primeros Unix, no por ningún motivo astronómico. El manual de 1971 contaba sesentavos de segundo desde el 1 de enero de ese mismo año, pero un contador de 32 bits a 60 Hz se desbordaba en poco más de un año y habría obligado a mover la época continuamente. Al pasar a segundos enteros eligieron el 1 de enero de 1970 —una fecha redonda, reciente y ya pasada— y ahí se quedó.
¿Qué es el problema del año 2038 y me afecta?
El 19 de enero de 2038 a las 03:14:07 UTC, un contador de segundos de 32 bits con signo se llena y da la vuelta hasta 1901. En un servidor Linux de 64 bits actual no hay nada que hacer, y las distribuciones de 32 bits llevan tiempo compilándose con time_t de 64 bits. Donde sí muerde es en dispositivos empotrados que no se actualizan, en columnas TIMESTAMP de MySQL, en formatos binarios con el campo fijado a 32 bits y, sobre todo, hoy mismo: cualquier cálculo que proyecte una fecha más allá de 2038 —una hipoteca, un certificado, una caducidad a largo plazo— ya está cruzando esa frontera.
¿El tiempo Unix cuenta los segundos intercalares?
No, y es deliberado. Un día son siempre 86 400 segundos, así que cuando se inserta un segundo intercalar el reloj Unix no avanza: repite el valor anterior o lo reparte poco a poco a lo largo de unas horas, que es lo que hacen los servidores NTP de Google y AWS. La consecuencia es que un timestamp no es el número real de segundos físicos transcurridos —desde 1972 se han insertado 27, el último el 31 de diciembre de 2016—, pero a cambio convertirlo en fecha es una división y no una consulta a una tabla que caduca. En 2022 se acordó dejar de insertarlos antes de 2035.
¿Por qué me sale una hora distinta a la que esperaba?
Casi siempre porque estás comparando una hora UTC con una hora local, o al revés. Un timestamp no lleva zona horaria dentro: es un instante absoluto, y la hora que le corresponde depende de dónde estés. Por eso esta herramienta muestra siempre las dos columnas. La misma trampa está en JavaScript: toISOString() devuelve UTC y toString() la hora local del equipo, y llamar a una u otra sobre la misma fecha da resultados que parecen contradictorios.
¿Cómo conviene guardar las fechas: en UTC, en timestamp, en texto?
Guarda el instante en UTC y conviértelo solo al mostrarlo: cuándo ocurrió algo es un dato absoluto, y UTC no tiene horario de verano ni cambia por decreto. Sobre el formato, si tu base de datos tiene un tipo nativo —timestamptz en PostgreSQL— úsalo: ocupa menos, se indexa mejor y valida lo que le metes; entre un entero y una cadena ISO 8601, el entero es compacto y la cadena es legible en un volcado y ordena igual de bien si termina en Z. La excepción son las citas futuras: «el martes que viene a las 9:00 en Madrid» no es un instante sino una hora de reloj en un lugar, y si la conviertes a UTC y luego cambia la regla del horario de verano, la cita se mueve. Para eso hay que guardar la fecha y la hora locales junto al nombre IANA de la zona.
¿Puede un timestamp ser negativo?
Sí, y es perfectamente correcto: −2208988800 es el 1 de enero de 1900. Los valores negativos son lo normal para fechas de nacimiento o registros históricos. Lo que pasa es que no todo el mundo los acepta: el tipo TIMESTAMP de MySQL arranca en 1970 y un time_t sin signo leería el mismo número como un futuro lejanísimo. Si trabajas con fechas anteriores a 1970, comprueba antes qué hace cada pieza de tu sistema con ellas.
Fuentes
Toda la información de esta página se refiere a: Conversor de Unix Timestamp.