Timestamp Unix
Convertir timestamp Unix a fecha, y al revés
Arriba, el timestamp de ahora mismo corriendo. Debajo, pega un número y sale la fecha —diciéndote si lo ha leído en segundos, milisegundos, micro o nanosegundos— o elige una fecha y sale el número. Todo a la vez en tu zona, en UTC y en la que tú elijas.
Los timestamps que pegas no salen de tu equipo: se convierten aquí dentro.
Por qué importa que esto no se suba
Un timestamp suelto parece un dato inofensivo, pero rara vez viene solo: se pega una columna entera sacada de un registro de producción, con el contexto de la incidencia que estabas depurando, o la marca de tiempo de un evento concreto de un cliente concreto. Nada de eso tiene por qué pasar por el servidor de nadie para convertirse en una fecha. Aquí ni siquiera hay a dónde enviarlo: incluso la base de datos de zonas horarias es la que ya trae tu navegador.
Cómo funciona, en 3 pasos
-
Pega el número, o elige la fecha
Los dos conversores están enfrentados y se hablan: al usar uno, el otro se pone al día solo.
-
Comprueba la unidad
Se te dice si lo ha leído en segundos, milisegundos, micro o nanosegundos. Si hay más de una lectura creíble, lo avisa y te enseña las otras.
-
Léelo en las tres zonas
Tu zona, UTC y la que elijas, cada una con ISO 8601, RFC 2822 y fecha legible, y cada formato con su botón de copiar.
Para qué la usa la gente
-
Leer un registroAparece un
1756252800en la traza de un error y hace falta saber cuándo fue exactamente, y en qué zona lo escribió el servidor. - Revisar una columna de una base de datosPegar cien marcas de tiempo y llevarse la columna convertida a la hoja de cálculo, sin escribir una consulta.
- Comprobar cuándo caduca un tokenEl campo de expiración de un JWT es un timestamp en segundos, y saber si ya venció es la mitad de la depuración.
- Cuadrar dos sistemasTu registro está en UTC y el del cliente en su hora local. Verlos juntos evita perder una tarde persiguiendo un desfase de dos horas.
- Escribir la consulta correctaCada base de datos tiene su función y nunca te acuerdas de cuál. Los fragmentos están listos con tu número dentro.
- Preparar datos de pruebaNecesitas el timestamp exacto de una fecha concreta para sembrar una base de datos o fijar un caso de prueba.
Segundos o milisegundos: la confusión que trae aquí a casi todo el mundo
Es la duda número uno, y tiene una regla fácil: se distingue por el número de cifras. Un timestamp en segundos para cualquier fecha entre 2001 y 2286 tiene diez cifras. En milisegundos tiene trece. Si empieza por 17 y tiene diez, son segundos y estás en 2025 o 2026.
Lo importante es que equivocarse no falla por poco. Leer segundos como si fueran milisegundos te deja en enero de 1970; leer milisegundos como segundos te manda al año 57000. Son errores tan grandes que se ven a simple vista… si te acuerdas de mirar.
¿Y por qué existe esta confusión? Por herencia. El timestamp Unix se definió en segundos, y eso devuelven las funciones clásicas: time() en C y en PHP, UNIX_TIMESTAMP() en MySQL, EXTRACT(EPOCH FROM …) en PostgreSQL. JavaScript llegó más tarde y decidió trabajar en milisegundos, así que Date.now() da tres cifras más; Java hace lo mismo. Y los sistemas que miden cosas rápidas —trazas, bases de datos de series temporales— usan microsegundos o nanosegundos. De ahí que el mismo instante aparezca con 10, 13, 16 o 19 cifras según de dónde salga.
Por eso esta herramienta no asume: prueba las cuatro lecturas, se queda con la que da una fecha creíble, te dice cuál ha usado y, si hay más de una posible, lo avisa y te enseña las otras para que decidas tú.
Qué es la época Unix
Es el instante desde el que se cuenta: la medianoche del 1 de enero de 1970 en UTC. Un timestamp Unix es sencillamente los segundos transcurridos desde ese momento. La fecha se eligió por comodidad a principios de los setenta, mientras se construía Unix: era redonda y estaba cerca.
La virtud del sistema es lo que no lleva. Un timestamp no tiene zona horaria, ni formato, ni idioma: es un número. El mismo instante es exactamente el mismo número en Tokio y en Madrid, y solo se convierte a una hora concreta cuando hay que enseñárselo a una persona. Por eso es la forma correcta de guardar un instante en una base de datos, y por eso guardar «27/08/2026 10:00» como texto acaba siempre en problemas.
El problema del año 2038
Muchos sistemas antiguos guardan el timestamp en un entero de 32 bits con signo, cuyo valor máximo es 2147483647. Ese número, leído como segundos desde 1970, es el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo más tarde el contador se desborda y se convierte en el número negativo más grande, que se interpreta como diciembre de 1901.
Es el mismo tipo de fallo que el efecto 2000, pero en binario en lugar de en dos dígitos decimales. Los sistemas modernos usan 64 bits, con los que el contador aguanta unos 292 000 millones de años, así que el asunto afecta sobre todo a equipos empotrados, control industrial y columnas antiguas de bases de datos que nadie ha migrado. Esta herramienta te avisa cuando el timestamp que miras pasa de ese límite, porque es justo cuando conviene acordarse.
Tres zonas a la vez, y por qué
El error más caro al depurar con timestamps no es convertir mal: es convertir bien en la zona equivocada. Miras un registro, lo conviertes, ves una hora que no cuadra con lo que ocurrió y te pasas la tarde buscando un fallo que no existe, cuando lo único que pasaba es que el servidor escribe en UTC y tú estabas leyendo la hora de tu ciudad.
Por eso el resultado sale simultáneamente en tu zona, en UTC y en una tercera que eliges —normalmente la del servidor o la del cliente que reportó el problema—. La comparación es inmediata y el malentendido no llega a ocurrir. Si lo que necesitas es planificar una reunión entre varias ciudades en lugar de depurar, eso lo hace mejor el planificador de zonas horarias.
La conversión inversa —de una fecha y hora en una zona concreta a un timestamp— tiene además dos casos con respuesta ambigua, y aquí se dicen en vez de callarlos: la noche en que los relojes se adelantan hay una hora que no existe, y la noche en que se atrasan hay una hora que ocurre dos veces, con dos timestamps distintos para el mismo reloj de pared. La herramienta detecta los dos casos y te lo explica.
Los nanosegundos, donde se pierde precisión en silencio
Este es un detalle que muchas herramientas hacen mal. Un timestamp en nanosegundos de 2026 vale unos 1,76 × 10¹⁸, y el mayor entero que JavaScript maneja sin perder precisión acaba en 9 × 10¹⁵. Convertirlo con las funciones normales pierde cifras sin avisar de nada, y puede desplazar el resultado un segundo entero: al construir esta herramienta lo comprobamos con 1756252800999999999, que por ese camino salta al segundo siguiente.
Aquí la división se hace con aritmética de enteros grandes, que es exacta. Con una salvedad honesta: la fecha que se muestra tiene resolución de milisegundos, porque es lo que representa el tipo de fecha del navegador. Los nanosegundos sirven para leer bien el instante, no para conservar la precisión completa.
Preguntas frecuentes
¿Mi timestamp está en segundos o en milisegundos?
Se distingue por las cifras: diez para segundos, trece para milisegundos, en cualquier fecha entre 2001 y 2286. Si empieza por 17 y tiene diez, son segundos y estás en 2025 o 2026.
Equivocarse no falla por poco: leer segundos como milisegundos te lleva a enero de 1970, y al revés te manda al año 57000. Por eso aquí no se asume: se prueban las cuatro lecturas, se elige la creíble y se te dice cuál se ha usado.
¿Por qué unos lenguajes dan segundos y otros milisegundos?
Por herencia. El timestamp se definió en segundos y eso devuelven time() en C y PHP, UNIX_TIMESTAMP() en MySQL o EXTRACT(EPOCH FROM …) en PostgreSQL.
JavaScript llegó después y trabaja en milisegundos, así que Date.now() da tres cifras más; Java igual. Y los sistemas de trazas o de series temporales usan microsegundos o nanosegundos. De ahí las 10, 13, 16 o 19 cifras.
¿Qué es exactamente la época Unix?
El instante desde el que se cuenta: la medianoche del 1 de enero de 1970 en UTC. Un timestamp son los segundos transcurridos desde ahí. La fecha se eligió por comodidad mientras se construía Unix.
Su virtud es lo que no lleva: no tiene zona, ni formato, ni idioma. El mismo instante es el mismo número en Tokio y en Madrid. Por eso es la forma correcta de guardar un instante en una base de datos.
¿Qué es el problema del año 2038?
Muchos sistemas antiguos guardan el timestamp en un entero de 32 bits con signo, cuyo máximo es 2147483647: el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después el contador se desborda y la fecha salta a diciembre de 1901.
Es el efecto 2000 en binario. Los sistemas modernos usan 64 bits y aguantan 292 000 millones de años, así que afecta sobre todo a equipos empotrados y a columnas antiguas. La herramienta te avisa al pasar ese límite.
¿Por qué el resultado sale en tres zonas?
Porque el error más caro al depurar no es convertir mal, sino convertir bien en la zona equivocada. Ves una hora que no cuadra y te pasas la tarde buscando un fallo que no existe.
Con tu zona, UTC y una tercera a elegir —la del servidor, la del cliente— la comparación es inmediata. Para planificar reuniones entre ciudades, mejor el planificador de zonas horarias.
¿Se puede fiar uno de esto para nanosegundos?
Para leer la fecha, sí, y no es lo habitual. Un timestamp en nanosegundos de 2026 vale 1,76 × 10¹⁸ y el entero seguro de JavaScript acaba en 9 × 10¹⁵: con las funciones normales se pierden cifras en silencio y el resultado puede irse un segundo entero.
Aquí la división usa aritmética de enteros grandes, que es exacta. Eso sí, la fecha mostrada tiene resolución de milisegundos, porque es lo que representa el tipo de fecha del navegador.
¿Qué pasa si elijo una hora que no existe?
Se te dice. La madrugada en que los relojes se adelantan hay una hora que no ocurre —en España, las 02:30 del último domingo de marzo—. Se detecta, se avisa y se usa la hora a la que el reloj salta de verdad.
Y la noche en que se atrasan, una hora ocurre dos veces: hay dos timestamps para el mismo reloj de pared. También se avisa, se usa el primero y se te recuerda que el otro está una hora más tarde.
¿Se envía a algún servidor lo que pego?
No. Todo se convierte en tu navegador, incluidas las zonas horarias, que salen de la base de datos de husos que ya trae el propio navegador. No hay cuentas ni base de datos. Carga la página, desconecta internet y compruébalo.