Convertidor de Timestamp Unix
Convierte timestamps Unix a fechas legibles y viceversa — con un reloj epoch en vivo.
Hora Unix Actual
clic para copiar
Timestamp → Fecha
Introduce un timestamp para convertirlo.
Fecha → Timestamp
Elige una fecha para obtener su timestamp.
El tiempo Unix es el número de segundos transcurridos desde la medianoche UTC del 1 de enero de 1970: un solo entero que se ha convertido silenciosamente en la forma en que casi todos los sistemas informáticos de la Tierra representan el tiempo. Tu teléfono, tu base de datos, las respuestas de las API y el archivo que guardaste esta mañana marcan los eventos así. La elegancia está en que un entero no tiene zonas horarias, ni horario de verano, ni ambigüedad de calendario: 1700000000 es el mismo instante en cualquier punto del planeta. Las complicaciones viven en los bordes —milisegundos frente a segundos, el problema de 2038 y los segundos intercalares—, y este conversor maneja la traducción en ambas direcciones.
Cómo funciona el conversor
Pega una marca de tiempo Unix para obtener la fecha legible tanto en UTC como en tu zona horaria local, o elige una fecha y hora para obtener su marca. El conversor detecta si tu entrada está en segundos, milisegundos, microsegundos o nanosegundos por su magnitud —una fuente común de confusión, ya que cada sistema usa resoluciones distintas— y muestra una lectura en vivo de la marca actual. Todo se ejecuta en tu navegador.
Los formatos
Segundos 1700000000 (10 dígitos, Unix clásico)
Milisegundos 1700000000000 (13 dígitos, JavaScript)
Microsegundos 1700000000000000 (16 dígitos, algunas BD)
Nanosegundos 1700000000000000000 (19 dígitos, Go, sistemas)
1700000000 = 2023-11-14 22:13:20 UTC
JS: Date.now() → milisegundos
Python: time.time() → segundos (float)
SQL: UNIX_TIMESTAMP(NOW()) → segundosLa confusión entre segundos y milisegundos es el bug clásico: pasa un valor en milisegundos donde se esperan segundos y tu fecha aterriza en el año 55.000; pasa segundos donde se esperan milisegundos y obtienes enero de 1970. El número de dígitos es la pista: diez dígitos son segundos hasta el año 2286, trece son milisegundos. Cualquier marca que decodifique a una fecha cercana a 1970 o absurdamente lejana en el futuro está casi con certeza en la unidad equivocada, no con datos equivocados.
Lo que conviene saber sobre el tiempo Unix
- 1Guarda las marcas de tiempo en UTC, siempre, y convierte a hora local solo para mostrar. Una marca Unix es inherentemente UTC: ese es todo su valor. En el momento en que guardas «hora local» heredas zonas horarias, transiciones de horario de verano y horas ambiguas. Todo desarrollador backend con experiencia aprendió esto una vez, y le salió caro.
- 2El problema del año 2038 es real pero está mayormente resuelto. Los enteros de 32 bits con signo se desbordan el 19 de enero de 2038 a las 03:14:07 UTC: un segundo después, saltan a 1901. Los sistemas modernos usan tiempo de 64 bits, suficiente para 292 mil millones de años, pero los dispositivos embebidos, los formatos antiguos y las bases de datos heredadas aún cargan con la suposición de 32 bits.
- 3El tiempo Unix ignora los segundos intercalares a propósito. Cuando se inserta uno, el tiempo Unix repite un segundo en lugar de contarlo, manteniendo cada día en exactamente 86.400 segundos. Eso hace limpia la aritmética y significa que técnicamente no es un recuento fiel de segundos físicos transcurridos: una distinción que solo importa en contextos científicos y astronómicos.
- 4Las marcas negativas son válidas y significan antes de 1970. −86400 es el 31 de diciembre de 1969. Los sistemas que tratan las marcas como sin signo, o siempre positivas, corrompen silenciosamente las fechas históricas: los cumpleaños de los años sesenta son la víctima clásica en formularios mal construidos.
- 5Cuidado con comparar marcas de distintas resoluciones. Una base de datos que guarda segundos comparada contra una API que devuelve milisegundos hace que cada evento parezca de 1970 o de un futuro lejano según la dirección. Cuando las marcas discrepan salvajemente, revisa las unidades antes que los datos.
Preguntas frecuentes
¿Por qué el 1 de enero de 1970?
Es esencialmente arbitrario: una fecha redonda y conveniente elegida por los desarrolladores de Unix en Bell Labs a principios de los setenta, lo bastante reciente para mantener los números pequeños en el hardware de la época. Versiones anteriores de Unix usaron de hecho épocas y unidades distintas antes de asentarse en segundos desde 1970. No tiene significado astronómico ni histórico; simplemente hacía falta algún punto fijo, y ese se quedó.
¿Cómo sé si una marca está en segundos o milisegundos?
Cuenta los dígitos. El tiempo Unix actual en segundos tiene diez dígitos (y seguirá teniéndolos hasta 2286); en milisegundos, trece; en microsegundos, dieciséis; en nanosegundos, diecinueve. Este conversor detecta automáticamente por magnitud. El síntoma de equivocarse es inconfundible: una fecha en 1970 significa que trataste milisegundos como si fueran segundos, y una fecha a decenas de miles de años significa lo contrario.
¿Qué es el problema del año 2038?
El Unix clásico almacenaba el tiempo como entero de 32 bits con signo, que alcanza su máximo —2.147.483.647— el 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después se desborda a un número negativo, que decodifica como diciembre de 1901. Los sistemas modernos de 64 bits no se ven afectados, pero los controladores embebidos, los formatos antiguos y el código heredado aún mantienen suposiciones de 32 bits, lo que lo convierte en un sucesor a cámara lenta, mayormente gestionado, del Y2K.
¿Maneja el tiempo Unix las zonas horarias?
No teniéndolas, que es la respuesta correcta. Una marca Unix identifica un instante, no una lectura de reloj de pared: 1700000000 es el mismo momento en Tokio y en Toronto; solo difiere su representación humana. Las zonas horarias entran exclusivamente al mostrar, cuando la marca se formatea para un espectador. Por eso almacenar marcas y mostrar fechas son, y deben seguir siendo, operaciones separadas.
¿Y los segundos intercalares?
El tiempo Unix finge que no existen. Cuando se añade un segundo intercalar al calendario civil, el tiempo Unix o repite un segundo o lo reparte entre las horas cercanas, según el sistema, manteniendo cada día en exactamente 86.400 segundos Unix. El intercambio es deliberado: la aritmética se mantiene trivialmente simple, a costa de no ser un recuento perfectamente fiel de segundos físicos. Para prácticamente todos los usos informáticos, el intercambio merece la pena.