Conversor de timestamp Unix (epoch a fecha)
Pega un timestamp y lee la fecha, o elige una fecha y lee el timestamp. Los segundos, milisegundos, microsegundos y nanosegundos se detectan por la cantidad de dígitos, y puedes forzar la interpretación si el número es poco común.
Ahora mismo
- Segundos
- Milisegundos
De timestamp a fecha
Las comas, los espacios y los guiones bajos se ignoran.
De fecha a timestamp
Qué cuenta en realidad un timestamp Unix
Un timestamp Unix es una cuenta de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC, el momento que todo el mundo llama epoch. No hay nada más dentro. Ni zona horaria, ni reglas de calendario, ni configuración regional: solo un número sobre una línea que se extiende hacia adelante y hacia atrás desde ese instante.
La parte que agarra desprevenida a la gente son los segundos intercalares. El tiempo POSIX define cada día como exactamente 86.400 segundos, así que cerca de dos docenas de segundos intercalares añadidos al tiempo civil desde 1972 no aparecen en la cuenta. Cuando se inserta uno, un timestamp repite un valor o se salta uno, según cómo lo suavice el sistema. La ventaja es que convertir un timestamp en una fecha es aritmética pura, sin tabla de consulta. El costo es que un timestamp Unix no puede nombrar un segundo intercalar en absoluto.
Segundos o milisegundos
Las herramientas Unix, la mayoría de las bases de datos SQL y muchas APIs cuentan segundos enteros. JavaScript, Java y todo lo que deriva de ellos cuentan milisegundos. Go y algunos sistemas de trazas usan nanosegundos. En la documentación a todos se los llama "el timestamp", y así es como entra el bug.
La longitud es la señal más rápida para cualquier fecha cercana al presente. Diez dígitos son segundos, trece son milisegundos, dieciséis son microsegundos, diecinueve son nanosegundos. Esas longitudes se mantienen estables durante mucho tiempo: un timestamp en segundos tiene diez dígitos desde septiembre de 2001 y los tendrá hasta 2286.
El modo de fallo es ruidoso en un sentido y silencioso en el otro. Si le pasas milisegundos a algo que espera segundos, aterrizas decenas de miles de años en el futuro, y alguien lo va a notar. Si le pasas segundos a algo que espera milisegundos, aterrizas en enero de 1970: una respuesta equivocada con toda la pinta de ser plausible, que además se ordena sin hacer ruido al principio de todas las listas. Si una fecha de tu aplicación muestra 1970, te equivocaste por un factor de 1000.
El problema del 2038
Un entero de 32 bits con signo se acaba en 2.147.483.647 segundos, que son las 03:14:07 UTC del 19 de enero de 2038. Un segundo después da la vuelta, se convierte en un número negativo y la fecha pasa a leerse diciembre de 1901.
El problema no es tu computadora. El valor de 32 bits sobrevive en firmware de sistemas embebidos, en código C viejo que nunca se volvió a compilar, en formatos de archivo y en columnas de bases de datos: el tipo TIMESTAMP de MySQL sigue topado en ese mismo instante de 2038, mientras que DATETIME no lo está. Si guardas la fecha de fin de una hipoteca o el vencimiento de un certificado en un campo de 32 bits, el bug ya está dentro de tus datos.
Un timestamp no tiene zona horaria
Vale la pena decirlo dos veces, porque causa más reportes de incidentes de los que el 2038 va a causar jamás. Un timestamp identifica un instante. La zona horaria se aplica cuando lo muestras, no cuando lo guardas. Dos personas que leen el mismo timestamp en Tokio y en Lisboa ven relojes de pared distintos y ninguna de las dos está equivocada.
El error clásico es el camino inverso: tomar los dígitos de un reloj local, llamar a mktime o su equivalente sin el desfase, y guardar el resultado. Eso guarda un instante desplazado justo por ese desfase, y el error cambia dos veces al año cuando se mueve el horario de verano. Si el valor vino del calendario de un usuario y no de un reloj, guarda el nombre de la zona junto a él: "las 09:00 en Europe/Madrid" y "un instante" son hechos distintos.
Dónde se detiene este conversor
- Solo dos zonas. Obtienes la zona de tu dispositivo y UTC. No hay selector de zonas, así que convertir a una tercera ciudad significa hacer la cuenta mentalmente.
- La entrada por debajo del milisegundo se trunca. Las fechas del navegador tienen resolución de milisegundos, así que los últimos tres dígitos de un timestamp en microsegundos y los últimos seis de uno en nanosegundos se descartan, no se redondean.
- Rango. Se rechaza cualquier cosa que esté a más de unos 8,64 × 1015 milisegundos del epoch; el rango admitido va del año -271821 al 275760.
- Las fechas antiguas se desvían. La hora local anterior a 1970 depende de datos históricos de zonas horarias que tu navegador quizá no tenga completos, así que las horas locales previas a 1970 pueden estar desviadas una hora o unos minutos. La línea de UTC siempre es correcta.
- El reloj es el de tu dispositivo. Las cifras de "ahora mismo" son tan exactas como la máquina en la que estás sentado.
Preguntas frecuentes
¿Qué es el epoch de Unix?
La medianoche UTC del 1 de enero de 1970. Se eligió como una fecha redonda y reciente que resultaba cómoda cuando se diseñó el manejo del tiempo en Unix, sin ninguna razón más profunda, y quedó. Los timestamps anteriores a ese instante son negativos.
¿Cómo sé si mi timestamp está en segundos o en milisegundos?
Cuenta los dígitos. Para cualquier fecha cercana a hoy, diez dígitos son segundos y trece son milisegundos. Si una fecha convertida cae en enero de 1970, le pasaste segundos a algo que esperaba milisegundos.
¿Un timestamp Unix puede ser negativo?
Sí: un valor negativo son esa cantidad de segundos antes de 1970. Esta herramienta los maneja, pero mucho software no: las columnas sin signo, algunas librerías de fechas y muchas APIs rechazan cualquier cosa por debajo de cero, así que conviene probar las fechas anteriores a 1970 en vez de darlas por sentadas.
¿Por qué el mismo timestamp muestra una hora distinta en la pantalla de mi colega?
Porque la línea local se muestra en la zona horaria que tenga configurada el dispositivo, y el timestamp en sí no lleva ninguna. Compara mejor la línea ISO 8601 en UTC: esa es idéntica en todas partes.
¿Qué pasa con los timestamps en 2038?
Los contadores de 32 bits con signo se desbordan el 19 de enero de 2038 y la fecha vuelve a 1901. Todo lo que usa tiempo de 64 bits está a salvo por más tiempo del que al universo le va a importar, pero los valores de 32 bits siguen presentes en firmware, en formatos de archivo viejos y en las columnas TIMESTAMP de MySQL.
Última actualización 19 de septiembre de 2026