Conversor Epoch/Unix
Convierte timestamps Unix a fechas legibles y viceversa. Indispensable para depurar APIs y logs.
Para qué sirve
Timestamps Unix al instante
Segundos y milisegundos
Detecta automáticamente si el timestamp es en segundos (10 dígitos) o milisegundos (13 dígitos).
100% privado
La conversión ocurre en tu navegador usando la API Date nativa de JavaScript. Sin servidores.
Múltiples formatos
Muestra el resultado en ISO 8601, UTC, fecha local y formato relativo (hace X días).
Instantáneo
La conversión es inmediata. También muestra el timestamp actual en tiempo real.
Cómo funciona
Tres pasos, sin complicaciones
Introduce el timestamp o la fecha
Pega un timestamp Unix (en segundos o milisegundos) o introduce una fecha en formato ISO 8601 para convertir en la dirección opuesta.
Selecciona la zona horaria
Elige tu zona horaria o UTC para ver la fecha local correcta. Los timestamps Unix siempre son UTC internamente.
Copia el resultado
Obtén la fecha formateada en múltiples formatos (ISO 8601, UTC, local) o el timestamp numérico. Un clic para copiar.
Preguntas frecuentes
¿Tienes dudas?
El Unix epoch (también llamado Unix time o POSIX time) es el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, excluyendo los segundos intercalares. Esta fecha de referencia fue elegida porque Unix fue desarrollado a finales de los 60 y se necesitaba un punto de partida conveniente. El tiempo Unix es continuo, uniforme y no depende de zonas horarias, lo que lo hace ideal para almacenar y comparar instantes en sistemas distribuidos.
Los sistemas Unix clásicos (C, Python datetime, bases de datos SQL) usan segundos. Los entornos JavaScript/Node.js, Java (System.currentTimeMillis()), y muchas APIs modernas usan milisegundos. Un timestamp en segundos tiene 10 dígitos (por ejemplo, 1704067200 para el 1 de enero de 2024), mientras que en milisegundos tiene 13 dígitos (1704067200000). Algunos sistemas usan microsegundos (16 dígitos) o nanosegundos (19 dígitos) para mediciones de alta precisión.
El problema Y2K38 (también llamado Year 2038 problem o Unix Millennium Bug) ocurrirá el 19 de enero de 2038 a las 03:14:07 UTC. En ese momento, el timestamp Unix almacenado como entero con signo de 32 bits (int32) alcanzará su valor máximo (2.147.483.647) y hará overflow, volviendo a un número negativo que los sistemas interpretarán como el 13 de diciembre de 1901. Los sistemas que usen int64 (enteros de 64 bits) no tendrán este problema hasta el año 292.277.026.596.
Los timestamps Unix tienen ventajas técnicas claras sobre las fechas formateadas: son un número simple (fácil de comparar, ordenar y serializar), no tienen ambigüedad de zona horaria (siempre representan el mismo instante UTC), no tienen ambigüedad de formato (MM/DD/YYYY vs DD/MM/YYYY), ocupan menos espacio (8 bytes como int64 frente a 24+ bytes como cadena ISO), y son más eficientes para operaciones de rango en índices de bases de datos.
Los timestamps Unix son siempre UTC — representan el mismo instante independientemente de donde estés. La zona horaria solo importa al convertir un timestamp a una representación humana legible (fecha y hora local) o al crear un timestamp desde una fecha local. Un error común es ignorar la zona horaria al parsear fechas y asumir hora local: esto causa errores de ±N horas dependiendo del offset de la zona horaria del sistema, difíciles de detectar porque los tests suelen correr en UTC.
Tiempo Unix: el reloj universal de los sistemas informáticos
El tiempo Unix es el estándar de facto para representar instantes temporales en sistemas informáticos. Su elegancia radica en su simplicidad: un único número entero que crece monotónicamente, sin ambigüedades de formato, zona horaria o calendario. Fue definido en la especificación POSIX y adoptado por todos los sistemas operativos derivados de Unix (Linux, macOS, BSD) y la mayoría de los lenguajes de programación modernos. La especificación POSIX.1-2008 lo define formalmente como el número de segundos desde la época Unix, con la peculiaridad de que los segundos intercalares (leap seconds) no se cuentan.
En el ecosistema de bases de datos, los timestamps Unix son ubicuos. PostgreSQL tiene el tipo TIMESTAMP que internamente almacena microsegundos desde la época Unix. MySQL tiene las funciones UNIX_TIMESTAMP() y FROM_UNIXTIME(). MongoDB almacena fechas como milisegundos desde la época en su tipo Date. Redis usa timestamps Unix para la expiración de claves (EXPIREAT). Los logs de sistemas como Apache, Nginx y syslog frecuentemente incluyen timestamps Unix para facilitar el procesamiento con herramientas como awk, grep y scripts de shell.
El problema Y2K38 es el equivalente moderno del Y2K original: los sistemas que almacenan timestamps como int32 con signo tendrán un overflow el 19 de enero de 2038. Aunque la mayoría de los sistemas modernos ya usan int64, el problema persiste en sistemas embebidos, firmware antiguo y código legado. La migración a int64 es la solución estándar. Convertir.ai muestra cuánto tiempo falta para el Y2K38 y permite verificar si un timestamp específico cae antes o después de esa fecha crítica.