El Unix timestamp — también llamado epoch time o tiempo POSIX — es la forma más universal de representar un momento en el tiempo en sistemas informáticos. Es un número entero que expresa cuántos segundos han transcurrido desde el 1 de enero de 1970 a las 00:00:00 UTC.
Así de simple. Y así de potente.
Por qué existe el Unix timestamp
Antes de que los sistemas informáticos tuvieran un estándar, cada plataforma almacenaba las fechas a su manera: algunos como string "1970-01-01", otros como días desde alguna época arbitraria, otros con zonas horarias implícitas que causaban caos cuando los sistemas se comunicaban entre sí.
Unix, desarrollado en los laboratorios Bell en los años 60 y 70, necesitaba una representación compacta, precisa y libre de ambigüedad. La solución fue elegir un punto de referencia universal — el 1 de enero de 1970 a medianoche UTC, conocido como la época Unix — y contar segundos desde ese instante.
Hoy ese estándar es universal. La misma base usan Linux, macOS, Windows, iOS, Android, JavaScript, Python, Go, Rust y prácticamente cualquier lenguaje o sistema operativo moderno.
Cómo trabajar con timestamps en JavaScript
JavaScript usa milisegundos (no segundos) desde la época Unix. Es importante tenerlo en cuenta cuando interactúas con APIs externas que suelen usar segundos.
Obtener el timestamp actual
// En milisegundos (JavaScript nativo)
Date.now(); // 1746316800000
// En segundos (como la mayoría de APIs externas)
Math.floor(Date.now() / 1000); // 1746316800
Convertir timestamp a fecha legible
const ts = 1746316800; // segundos
const date = new Date(ts * 1000); // × 1000 porque JS usa milisegundos
date.toISOString(); // "2025-05-04T00:00:00.000Z"
date.toLocaleDateString(); // depende del locale del sistema
date.toUTCString(); // "Sun, 04 May 2025 00:00:00 GMT"
Convertir fecha a timestamp
const date = new Date("2025-05-04T00:00:00Z");
const timestamp = Math.floor(date.getTime() / 1000); // 1746316800
Calcular diferencias entre fechas
const inicio = 1746316800;
const fin = 1746403200;
const difSeg = fin - inicio; // 86400 segundos
const difHor = difSeg / 3600; // 24 horas
const difDia = difSeg / 86400; // 1 día
Los timestamps hacen triviales las operaciones aritméticas con fechas, algo que con strings requiere parseo complejo y genera errores de zona horaria.
Formatos relacionados
ISO 8601 es el estándar internacional para representar fechas como texto: 2025-05-04T00:00:00Z. La Z indica UTC. JavaScript lo genera con date.toISOString(). Es el formato recomendado para APIs REST.
RFC 2822 es el formato de las cabeceras de email y HTTP: Sun, 04 May 2025 00:00:00 GMT. Más legible para humanos, menos adecuado para parseo automático.
Tiempo relativo: en lugar de una fecha absoluta, indica cuánto tiempo ha pasado: "hace 3 horas", "ayer", "el martes pasado". Se calcula con Math.floor((Date.now() / 1000) - timestampPasado).
El bug del año 2038
Aquí viene la parte que mantiene despiertos a los ingenieros de sistemas legacy.
Los sistemas de 32 bits almacenan el timestamp Unix como un entero con signo de 32 bits (int32_t). El valor máximo representable es 2.147.483.647.
Ese número en segundos desde 1970 corresponde exactamente al 19 de enero de 2038 a las 03:14:07 UTC.
Un segundo después, el contador hace overflow y salta al valor negativo más bajo (-2.147.483.648), que corresponde al 13 de diciembre de 1901. Los sistemas basados en esa variable interpretarán que los relojes retrocedieron 136 años.
¿A qué sistemas afecta realmente?
Los sistemas de 64 bits no tienen ningún problema: un int64_t puede representar timestamps hasta el año 292.277.026.596. Tiempo de sobra.
El riesgo está en:
- Sistemas embebidos con procesadores de 32 bits — routers antiguos, maquinaria industrial, sistemas SCADA, equipos médicos
- Kernels Linux de 32 bits — aunque ya existen parches (el kernel 5.6 de Linux lo resolvió para arquitecturas de 32 bits)
- Bases de datos legacy con columnas de timestamp almacenadas como
INTde 32 bits - Código C/C++ antiguo que usa
time_tdefinido comoint32_ten algunos compiladores
JavaScript no tiene este problema. Usa float64 (IEEE 754 doble precisión) para sus timestamps en milisegundos. El valor máximo seguro es 9.007.199.254.740.991, que corresponde al año 275.760.
Comparativa con Y2K
El bug del año 2000 (Y2K) afectaba a sistemas que almacenaban el año con solo 2 dígitos. La corrección fue urgente porque el año 2000 llegó para todos simultáneamente.
El bug de 2038 es diferente: afecta a sistemas específicos, existe amplia documentación sobre cómo migrarlo y hay 12 años de margen. Pero la complacencia es el mayor riesgo — sistemas que llevan décadas funcionando sin mantenimiento son los más vulnerables.
Timestamps y zonas horarias
El Unix timestamp es siempre UTC. No tiene zona horaria implícita. 1746316800 siempre significa el mismo instante en el tiempo, independientemente de si lo lees en Madrid o en Tokio.
La confusión surge al convertir a fecha legible. new Date(1746316800000).toLocaleDateString() en España (UTC+2 en verano) mostrará una fecha diferente que el mismo código ejecutado en un servidor en UTC.
Regla de oro: almacena siempre en UTC (timestamp o ISO 8601 con Z). Convierte a hora local solo cuando vayas a mostrar la fecha al usuario final.
Pruébalo sin código
Si necesitas convertir un timestamp Unix a fecha legible, obtener el timestamp actual, calcular diferencias entre fechas o explorar formatos ISO 8601 y UTC, nuestro conversor de timestamps online lo hace al instante, con soporte completo para todos los formatos.