Convertidor de marca de tiempo Unix gratuito

¿Qué es una marca de tiempo Unix?

Una marca de tiempo Unix (también llamada epoch time o POSIX time) es el número de segundos transcurridos desde el 1 de enero de 1970, 00:00:00 UTC. Es una forma sencilla e independiente de la zona horaria de representar un punto en el tiempo y se utiliza ampliamente en programación, bases de datos, APIs y registros de servidores.

Por ejemplo, la marca de tiempo 1700000000 representa el 14 de noviembre de 2023 a las 22:13:20 UTC. JavaScript usa marcas de tiempo en milisegundos (multiplicar por 1000), mientras que la mayoría de los demás lenguajes y APIs usan segundos.

Preguntas frecuentes

¿Qué formatos de fecha puedo introducir?

Puedes introducir fechas en la mayoría de los formatos estándar: ISO 8601 (2025-12-31T23:59:59Z), cadenas de fecha comunes (Dec 31, 2025 11:59 PM) o formatos simples como 2025-12-31 23:59:59. El convertidor usa el analizador de fechas integrado del navegador.

¿Detecta automáticamente segundos vs. milisegundos?

Sí. Si la marca de tiempo es mayor que 1 billón, el convertidor la trata como milisegundos. De lo contrario, la trata como segundos. Ambos formatos se muestran en la tabla de resultados.

¿Qué es el problema del año 2038?

Los sistemas que almacenan marcas de tiempo Unix como enteros con signo de 32 bits se desbordarán el 19 de enero de 2038 a las 03:14:07 UTC. Los sistemas modernos usan enteros de 64 bits, que pueden representar fechas miles de millones de años en el futuro. Esta herramienta utiliza el tipo Number de JavaScript, que maneja marcas de tiempo mucho más allá de 2038.

¿Por qué el 1 de enero de 1970?

Un timestamp Unix es un contador entero de segundos transcurridos desde la época Unix, 00:00:00 UTC del jueves 1 de enero de 1970. Es un escalar único que identifica sin ambigüedad un instante en el tiempo, independiente del calendario y de las zonas horarias: el mismo número nombra el mismo instante estés en Tokio o en Toronto.

La elección de 1970 fue algo arbitraria, pero no aleatoria. La primera edición del UNIX Programmer's Manual (noviembre de 1971) definía el tiempo del sistema como el número de ticks de reloj a 60 Hz desde el 1971-01-01. Con un entero sin signo de 32 bits contando a 60 Hz, el sistema solo abarcaba unos 2,26 años antes del desbordamiento, un problema que se hizo obvio rápido. Al preparar la segunda edición en 1972, el equipo de Ken Thompson y Dennis Ritchie pasó a contar segundos desde el 1970-01-01: enteros con signo de 32 bits contando segundos durarían unos 68 años, holgadamente más allá de la vida laboral de los ingenieros que escribían el código, y el Año Nuevo más reciente antes del inicio del proyecto facilitaba la aritmética. No hubo votación de comité ni proceso de estandarización al estilo IANA. La elección cuajó porque Unix salió con ella, y una vez que cien millones de máquinas estaban contando desde ese instante, ningún reemplazo era viable.

POSIX (1988) codificó la época 1970 bajo IEEE Std 1003.1 como «Seconds Since the Epoch». Hoy, la misma época sostiene C/C++ time_t, Python time.time(), Ruby Time.now.to_i, JavaScript y Java (en milisegundos, ver abajo), los timestamps de sistemas de archivos Linux/macOS, las cabeceras de bloque de Bitcoin y Ethereum, y las reclamaciones JWT iat/exp/nbf. Un puñado de sistemas usan épocas distintas (Windows FILETIME cuenta ticks de 100 ns desde 1601-01-01, .NET DateTime ticks desde 0001-01-01), pero el tiempo Unix es la lingua franca para cualquier cosa que cruce una frontera de SO o de lenguaje.

Segundos contra milisegundos, el bug más habitual

POSIX define el timestamp como segundos desde la época. Toda librería C, todo intérprete Python, todo runtime Ruby/Go/Rust/Elixir devuelve segundos. JavaScript es la famosa excepción, Date.now() y new Date().getTime() devuelven milisegundos. System.currentTimeMillis() de Java sigue la misma convención, y varios sistemas de base de datos más nuevos (por ejemplo el tipo Date BSON de MongoDB) también almacenan milisegundos.

Resultado: un bug perpetuo entre lenguajes. Un backend Go escribe 1700000000 (segundos) en un campo JSON; un cliente Node.js lo pasa a new Date(1700000000), pero JavaScript espera milisegundos, así que la fecha resultante es 1970-01-20 en vez de finales de 2023. La solución es new Date(1700000000 * 1000). A la inversa, enviar un timestamp JS en milisegundos a datetime.fromtimestamp() de Python da el año ~55895. Stack Overflow tiene decenas de variantes de la pregunta «JavaScript Date showing 1970», y el desajuste es la causa raíz en la gran mayoría.

Este conversor implementa una heurística: si la entrada es mayor que 1.000.000.000.000, la trata como milisegundos; si no, como segundos. Funciona porque 1e12 segundos sería el año 33658 d.C. (bien lejos de cualquier entrada real a escala de segundos), mientras que 1e12 milisegundos es el 9 de septiembre de 2001 UTC (dentro del rango moderno). Los timestamps en microsegundos y nanosegundos usados por algunos sistemas científicos y las API del kernel Linux empujarían el umbral más arriba; para esos, hay que especificar la precisión explícitamente.

El problema del año 2038 («Y2K38»)

Un entero con signo de 32 bits guarda valores de −2.147.483.648 a +2.147.483.647. Interpretado como segundos desde 1970-01-01 UTC, el momento máximo representable es 03:14:07 UTC del martes 19 de enero de 2038. Un segundo más tarde, el contador desborda y salta al valor más negativo, que decodifica como 20:45:52 UTC del viernes 13 de diciembre de 1901. Cualquier time_t de 32 bits, toda columna de base que guarde un entero con signo de 4 bytes para el tiempo, y todo sistema embebido cuyo firmware sea anterior a ~2010 está en riesgo.

La superficie expuesta es incómoda: PLC industriales y controladores SCADA con ciclos de vida de despliegue de 15 a 30 años instalándose hoy; antiguas columnas TIMESTAMP de MySQL documentadas como saturándose en el límite de 2038; sistemas de archivos ext3; formatos de protocolo binario (campos RRSIG de DNSSEC, NTPv3, varios buses de campo industriales) que empaquetan un timestamp de 4 bytes; smart TV e infotainment de coche corriendo silenciosamente kernels Linux 32 bits antiguos. La solución dominante es ensanchar time_t a 64 bits, lo que extiende el máximo a unos +292 mil millones de años, más allá de la muerte térmica del Sol. Linux 5.6 (marzo de 2020) añadió las syscalls de tiempo de 64 bits a todas las arquitecturas 32 bits vía el patchset y2038 de Arnd Bergmann; glibc 2.34 (agosto de 2021) hizo time_t de 64 bits opt-in vía _TIME_BITS=64; Debian 13 «Trixie» (2025) es la primera release con el archivo entero recompilado. Apple deprecó los binarios 32 bits en macOS 10.15 (2019) e iOS 11 (2017), así que el parque de consumo está efectivamente inmune.

La superficie de riesgo restante es abrumadoramente embebida y datos heredados en disco: un kernel 64 bits leyendo una columna de timestamp de 32 bits de una base de datos heredada está tan roto como la propia base. La migración es un problema de formato de datos por aplicación, no solo un problema de kernel.

JavaScript Date, la API más maldita del campo

El objeto Date de JavaScript se copió íntegro de Java 1.0 en mayo de 1995 durante el sprint de 10 días en el que Brendan Eich escribió el LiveScript original. Java mismo deprecó la mayoría de los métodos de java.util.Date en JDK 1.1 (1997), pero JavaScript los heredó y no podía romper la compatibilidad web, así que se quedaron. El resultado es una API en la que:

• Los meses están indexados a 0 (new Date(2024, 0, 15) = 15 de enero) pero los días están indexados a 1.
• getYear() devuelve «año menos 1900», getYear() para 2024 es 124. getFullYear() se añadió después para devolver 2024 directamente.
• Date.parse('2024-03-15') se interpreta como medianoche UTC; Date.parse('2024/03/15') es medianoche local; Date.parse('March 15, 2024') queda definido por la implementación.
• Antes de ECMAScript 5 (diciembre de 2009) el parseo estaba casi enteramente definido por la implementación, la misma cadena de entrada podía dar diferentes valores Date entre IE, Firefox, Chrome y Safari.

La API Temporal (TC39 Stage 3 desde marzo de 2021) es el reemplazo moderno, ofreciendo Temporal.Instant, Temporal.PlainDate, Temporal.PlainTime, Temporal.ZonedDateTime y un tipo Temporal.Duration de verdad. El soporte de navegadores está desplegándose (Firefox Nightly, Safari 18 parcial, Chrome detrás de un flag en 2024); los polyfills funcionan pero suman ~25 KB. Moment.js fue puesto en modo mantenimiento por sus mantenedores en septiembre de 2020, para proyectos nuevos en 2026 la recomendación es Temporal primero si el soporte de navegador lo permite, Luxon o date-fns si no, y Moment.js nunca.

Cuándo recurres a esto

• Depurar respuestas de API. La mayoría de APIs JSON devuelven timestamps como enteros Unix o como cadenas ISO 8601, y muchos mezclan. Pegar un número en un conversor decenas de veces al día es el caso de uso de mayor volumen.
• Análisis de logs. syslog, journald, AWS CloudWatch y la mayoría de logs de aplicación llevan sello temporal en segundos Unix. Los ingenieros copian un timestamp de una línea de log y necesitan saber el equivalente de reloj de pared.
• Inspección de columnas de fecha en BD. Una consulta puntual psql o mysql devuelve 1700000000; la BD tiene funciones como FROM_UNIXTIME(), pero una herramienta de navegador es más rápida para trabajo ad hoc.
• Inspección de JWT. Decodificar un token OAuth muestra "exp": 1738367200. ¿Está caducado? ¿Cuándo caduca? Un conversor de timestamp es la respuesta más rápida.
• Timestamps de blockchain. El nTime de bloque Bitcoin va en segundos Unix (desborda en 2106, 4 bytes sin signo). Los timestamps de bloque Ethereum también en segundos Unix.
• Metadatos de sistema de archivos del SO. ls -l --time-style=+%s imprime mtimes Unix; stat -c '%Y' filename devuelve mtime como entero. La reconciliación forense de timestamps suele pasar por decodificación manual.
• Certificado notBefore / notAfter y cabeceras HTTP If-Modified-Since, todos timestamps que ocasionalmente hay que decodificar.

Una nota sobre los segundos intercalares

Desde 1972, se han insertado 27 segundos intercalares en UTC para mantener la hora de reloj alineada con la rotación cada vez más lenta de la Tierra. El más reciente fue el 31 de diciembre de 2016 23:59:60 UTC. El tiempo Unix no codifica los segundos intercalares, POSIX dice explícitamente que un timestamp Unix finge que cada día tiene exactamente 86.400 segundos. Los sistemas Linux antiguos «repiten» el último segundo; Google y AWS usan un «leap smear» que reparte el segundo extra a lo largo de una ventana de 24 horas. En cualquier caso, el tiempo Unix nunca lee 23:59:60 en almacenamiento, y restar dos timestamps que cruzan un segundo intercalar produce una respuesta un segundo corta respecto al tiempo SI realmente transcurrido. Para el código de aplicación es invisible. Para software astronómico o de trading financiero puede importar. En noviembre de 2022, la 27ª Conferencia General de Pesos y Medidas votó dejar de insertar segundos intercalares para 2035, sustituyéndolos por un ajuste periódico mucho mayor.

Referencia rápida

Timestamp	UTC datetime	Note
0	1970-01-01 00:00:00	The epoch
1,000,000,000	2001-09-09 01:46:40	First "billion-second" milestone
1,234,567,890	2009-02-13 23:31:30	"Cool number" celebrated by some devs
1,700,000,000	2023-11-14 22:13:20
2,000,000,000	2033-05-18 03:33:20	"Two billionth second"
2,147,483,647	2038-01-19 03:14:07	Last second representable in signed 32-bit
4,294,967,295	2106-02-07 06:28:15	Last representable in unsigned 32-bit (Bitcoin's nTime limit)
9,999,999,999	2286-11-20 17:46:39	Last 10-digit timestamp

Más preguntas

¿Por qué el mismo timestamp muestra una hora distinta en la máquina de mi amistad?

Porque el número subyacente es UTC, pero el display convierte a hora local. 1700000000 es 22:13:20 UTC, pero 17:13:20 en Nueva York y 06:13:20 al día siguiente en Sídney. El número es el mismo; solo difiere el renderizado. Para descartar confusión de zona horaria, pide a ambas máquinas mostrar en UTC.

¿Cuál es la diferencia entre Y2K e Y2K38?

Y2K (año 2000) fue un problema de lógica en el código de aplicación: muchos sistemas guardaban los años con dos dígitos ASCII, así que «00» se volvía ambiguo entre 1900 y 2000. Cada aplicación había que inspeccionarla y parchearla por separado; el coste mundial total de remediación se estimó en 300-600 mil millones de dólares. Y2K38 es sobre todo un problema de tipo de datos en bibliotecas de bajo nivel, recompilar la lib C y el kernel contra un time_t de 64 bits arregla gran parte de la superficie para toda aplicación que enlace con ellas. Los casos duros restantes son datos persistidos en disco (bases de datos, metadatos de archivos, protocolos binarios) que requieren tooling de migración de datos. La sabiduría convencional es que 2038 será un evento más pequeño y menos noticiable que 2000, con más fallos localizados en aparatos embebidos y menos cortes de portada.

¿Por qué new Date('2024-03-15') a veces muestra el 14 de marzo?

Porque esa cadena se interpreta como medianoche UTC según el estándar ES5, y luego se muestra en tu zona horaria local. En una zona UTC-8 como US Pacific, medianoche UTC del 15 de marzo son las 16:00 del 14 de marzo en hora local, así que .getDate() devuelve 14. La solución en código moderno es o bien new Date('2024-03-15T12:00:00') (que JavaScript interpreta como mediodía local cuando omites la Z) o, mejor, la API Temporal.PlainDate.from() cuando se publique.

¿Se envía algo a un servidor?

No. La conversión es aritmética JavaScript corriendo en local en tu navegador. Nada acerca de los timestamps que introduzcas sale de la página, útil cuando los valores son IDs de cliente, líneas internas de log o datos de depuración de sesión que prefieres no subir a ningún sitio. La página funciona sin conexión una vez cargada.

Herramientas relacionadas