En una frase
El tiempo Epoch es la forma que tiene una computadora de registrar el tiempo como un único número que siempre aumenta: el total de segundos que han pasado desde la medianoche UTC del 1 de enero de 1970.
El problema que resuelve
Los humanos y el tiempo tenemos una relación complicada. Tenemos zonas horarias, horarios de verano y formatos como MM/DD/YYYY vs. DD/MM/YYYY. Escribimos "8 de octubre de 2024 a las 3:00 PM", pero eso significa algo diferente en Tokio que en Toronto. Es un desastre de ambigüedad.
Las computadoras, por otro lado, detestan la ambigüedad. Necesitan una forma única, universal y matemáticamente simple de representar un momento en el tiempo. Intentar hacer cálculos con "8 de octubre" es una pesadilla. Pero ¿hacer cálculos con un simple número? Para eso están hechas las computadoras.
Este es el problema que el tiempo Unix (también llamado tiempo Epoch o tiempo POSIX) fue creado para resolver. Allá por los inicios del sistema operativo Unix en los años 70, sus creadores necesitaron un sistema sencillo para llevar la cuenta del tiempo. Decidieron elegir un punto de partida arbitrario —una «época» o epoch— y simplemente... contar.
La epoch elegida fue 00:00:00 UTC, 1 de enero de 1970. ¿Por qué esa fecha? Era una fecha redonda y bonita, y lo suficientemente reciente para la tecnología de la época.
A partir de ese momento, cada segundo que pasa incrementa un contador universal. Así que, en lugar de que una computadora tenga que interpretar "3:00 PM del 8 de octubre de 2024, en Toronto (que es EDT)", puede simplemente almacenar el número 1728409200. Ese número representa ese momento exacto en el tiempo, en todas partes de la Tierra, simultáneamente. Sin zonas horarias, sin formatos, sin "¿es AM o PM?". Solo un número. Problema resuelto.
Cómo funciona por dentro
En el fondo, el concepto es súper simple. Pero como todo en la tecnología, el diablo está en los detalles.
La Época y la Unidad
Todo el sistema se basa en dos ideas:
- El Punto de Partida (Época o Epoch): Está fijado en
1970-01-01T00:00:00Z. LaZviene de Zulu, un término militar y de aviación para UTC (Tiempo Universal Coordinado). En el mundo del tiempo Epoch, este momento es simplemente0. - La Unidad de Medida: La unidad estándar y oficial es el segundo.
Entonces, el timestamp 1 representa 1970-01-01T00:00:01Z. El timestamp para el inicio del día siguiente, 1970-01-02T00:00:00Z, es 86400 (porque hay 60 segundos * 60 minutos * 24 horas = 86,400 segundos en un día).
// A date far in the future
const humanDate = new Date('2035-10-26T10:00:00Z');
// Its corresponding Epoch timestamp in seconds
const epochTimestamp = 2071754400;
Cuando tu computadora te muestra este timestamp como una hora local, está haciendo una conversión por detrás. Toma el timestamp universal en UTC y le aplica el desfase de la zona horaria de tu sistema para mostrarlo de una manera que tenga sentido para ti. El número subyacente, sin embargo, permanece puro y universal.
Variaciones: Milisegundos, Microsegundos, Nanosegundos
A veces, necesitas medir cosas que suceden más rápido que un segundo. Para esto, los sistemas utilizan versiones más precisas del timestamp Epoch. El principio es el mismo, pero la unidad cambia.
| Unidad | Valor de Ejemplo (para el mismo momento) | Cantidad de Dígitos Común | Caso de Uso Típico |
|---|---|---|---|
| Segundos | 1728409200 |
10 | El estándar POSIX; APIs, bases de datos. |
| Milisegundos | 1728409200123 |
13 | JavaScript (Date.now()), APIs modernas. |
| Microsegundos | 1728409200123456 |
16 | Sistemas de alto rendimiento, algunas bases de datos. |
| Nanosegundos | 1728409200123456789 |
19 | Computación científica, lenguaje Go. |
Esta es la fuente número uno de bugs cuando se trabaja con timestamps. Si un sistema te da un número de 13 dígitos y lo tratas como segundos, estás intentando calcular una fecha a miles de años en el futuro. Siempre revisa la documentación o fíjate en la cantidad de dígitos para saber con qué estás tratando.
El «Problema del Año 2038»
Esta es una pieza clásica del folklore informático. Muchos sistemas antiguos, para ahorrar la valiosa memoria, almacenaban el timestamp Epoch como un entero de 32 bits con signo.
Un "bit" es un 1 o un 0. "32 bits" significa que tienes 32 espacios para 1s y 0s. "Con signo" significa que uno de esos bits se usa para indicar si el número es positivo o negativo. Esto deja 31 bits para el número en sí, que puede representar un valor máximo de 2^31 - 1, o 2,147,483,647.
¿Qué pasa cuando el número de segundos desde 1970 alcance ese límite? Sucederá el martes, 19 de enero de 2038, a las 03:14:07 UTC. Justo al segundo siguiente, el entero se desbordará. Como el odómetro de un carro que pasa de 999999 a 000000, el timestamp de 32 bits se reiniciará a su valor más negativo (-2,147,483,648). Esto corresponde a una fecha en diciembre de 1901.
Para cualquier sistema de 32 bits que no haya sido parchado, esto causará un caos cronológico. Piensa en los sistemas embebidos en carros antiguos, equipos industriales o routers de red.
¿La solución? Usar un entero de 64 bits. Un entero de 64 bits puede almacenar un número tan absurdamente grande que no se desbordará hasta dentro de unos 292 mil millones de años. Para entonces, el Sol ya se habrá expandido y tragado la Tierra, así que probablemente podamos considerarla una solución permanente. La mayoría de los sistemas operativos y lenguajes modernos ya han hecho el cambio.
Segundos Intercalares: El Pelo en la Sopa
La rotación de la Tierra no es perfectamente regular; se está desacelerando ligeramente. Para mantener nuestros relojes atómicos (que son súper regulares) sincronizados con el día solar, los organismos internacionales ocasionalmente añaden un "segundo intercalar" al calendario. Esto significa que un minuto podría tener 61 segundos (p. ej., 23:59:60).
¿Y cómo maneja esto el tiempo Epoch? Pues no lo hace.
Oficialmente, el estándar POSIX ignora los segundos intercalares. Asume que cada día tiene exactamente 86,400 segundos. Cuando ocurre un segundo intercalar, los sistemas lo manejan de varias maneras, pero una común es repetir efectivamente el segundo anterior. El timestamp para 23:59:59 podría ocurrir dos veces. Esto mantiene la cuenta continua e ininterrumpida de segundos, pero significa que un timestamp de Unix no siempre se corresponde perfectamente con el UTC del mundo real. Para el 99.9% de las aplicaciones, esto no es un problema. Para el trading de alta frecuencia o la medición científica, es un tremendo dolor de cabeza.
Historias del mundo real
El Caso del Caché que Viajaba en el Tiempo
Un equipo de desarrollo estaba lanzando una nueva funcionalidad respaldada por un sistema de caché. Para mejorar el rendimiento, guardaban los datos en caché durante una hora. La lógica era simple: tiempo_expiracion = tiempo_actual() + 3600. Desplegaron el código en toda su flota de servidores.
De repente, empezaron a llover bugs extraños. Los datos desaparecían del caché casi al instante. Después de horas de debugging frenético, encontraron al culpable. Uno de los nuevos servidores de la flota tenía el reloj de su sistema mal configurado: estaba cinco minutos atrasado respecto a todos los demás servidores.
Cuando la solicitud de un usuario llegaba a un servidor correcto, guardaba los datos en caché con un tiempo de expiración de, digamos, 1678886400 (12:00 PM). Si una solicitud posterior para esos mismos datos llegaba al servidor "lento", su reloj marcaba las 11:55 AM. Al revisar el caché, veía un tiempo de expiración de las 12:00 PM y servía los datos correctamente. Pero si la primera solicitud llegaba al servidor lento, establecería un tiempo de expiración de 1678882800 (11:00 AM, su propia hora, más una hora que son las 12:00 PM). Pero eran las 11:55 AM. Espera, eso no está bien.
Intentémoslo de nuevo. La hora del Servidor A es 12:00. Establece una expiración de caché para 12:00 + 1 hora = 13:00. El reloj del Servidor B está lento; cree que son las 11:55. Cuando el Servidor B necesita escribir en el caché, establece una expiración de 11:55 + 1 hora = 12:55. Ahora, si el Servidor A ve un ítem que expira a las 12:55, pensará que le quedan 55 minutos, mientras que el Servidor B piensa que tiene una hora completa. Esto lleva a inconsistencias.
El verdadero caos comienza cuando los relojes están muy desfasados. Si el reloj del Servidor B estuviera una hora atrasado (piensa que son las 11:00 cuando son las 12:00), establecería un tiempo de expiración de 11:00 + 1 hora = 12:00. Desde la perspectiva del Servidor A, este nuevo ítem del caché expira en el mismo segundo en que fue creado. Los datos, en la práctica, se desvanecían.
Lección: Los timestamps de Unix son absolutos, pero se generan a partir de relojes de sistema que podrían no serlo. En sistemas distribuidos, mantener los relojes sincronizados (normalmente con el Protocolo de Tiempo de Red, o NTP) no es solo una buena práctica; es crítico.
La API que Hablaba en Milisegundos
Un desarrollador frontend estaba construyendo un dashboard para mostrar la actividad de los usuarios. La API del backend proporcionaba un campo last_login con un timestamp, como 1678886400. El desarrollador usó una librería de JavaScript para mostrar esto: new Date(1678886400).
El resultado fue extraño. El último inicio de sesión de cada usuario se mostraba como "20 de enero de 1970". ¿Qué estaba pasando?
El desarrollador pasó una hora culpando a la librería, a su código y a la fase de la luna. Finalmente, intentó integrar un endpoint diferente de la misma API. Esta vez, el timestamp era 1678886400123. ¡Tenía 13 dígitos! De repente, todo encajó. El constructor del objeto Date de JavaScript espera un timestamp en milisegundos, no en segundos.
El backend estaba enviando un timestamp estándar de 10 dígitos basado en segundos. El frontend estaba interpretando 1,678,886,400 como el número de milisegundos desde la época, que es una fecha apenas unas semanas después del inicio de la época en 1970. La solución era simple: new Date(1678886400 * 1000).
Lección: Siempre, siempre, siempre verifica la precisión de un timestamp. Una diferencia de tres ceros es la diferencia entre hoy y 1970.
Errores y trampas comunes
Olvidarse de la zona horaria. Los timestamps Unix están siempre, sin excepción, en UTC. Cuando conviertes uno a una fecha legible para humanos, tu lenguaje de programación o herramienta casi siempre usará la zona horaria local de tu computadora. Esto puede causar una confusión masiva si no lo tienes en cuenta.
1728409200es un momento exacto en el tiempo, pero se mostrará como06:00en Nueva York y19:00en Tokio. El número es la verdad; lo que se muestra es una interpretación.Mezclar segundos y milisegundos. Este es el clásico error "off-by-1000". Es el bug más común al trabajar con timestamps. Como regla general: 10 dígitos son segundos, 13 dígitos son milisegundos. Si ves algo diferente, desconfía mucho.
Ignorar el problema del 2038. Si estás construyendo una aplicación web estándar en un lenguaje moderno, probablemente estés a salvo. Pero si estás escribiendo código en C para un dispositivo IoT embebido, el sistema de infoentretenimiento de un carro, o manteniendo un sistema legacy de 32 bits, el bug Y2038 es una bomba de tiempo muy real.
Usar strings ambiguos para generar timestamps. Crear un timestamp a partir de un string como "15 de marzo de 2025 10:00 PM" es buscarse problemas. ¿Es en tu zona horaria local? ¿La del servidor? ¿UTC? Siempre genera los timestamps a partir de objetos que consideren la zona horaria o usa strings UTC explícitos (como el formato ISO 8601:
2025-03-15T22:00:00Z).
Por qué deberías tenerlo en el radar
Simplemente no puedes ser un desarrollador moderno sin entender el tiempo Epoch. Es la lingua franca del tiempo en la computación. Te lo encontrarás en todas partes:
- APIs: Los payloads JSON lo usan constantemente para campos como
createdAt,updatedAtyexpires_at. - JWTs: Los claims
exp(expiración),iat(emitido en) ynbf(no antes de) son todos timestamps Unix estándar. - Bases de datos: Almacenar el tiempo como un solo entero suele ser más eficiente para la indexación y el almacenamiento que usar un tipo complejo como
DATETIME. - Archivos de Log: Usar timestamps numéricos hace que sea trivial correlacionar eventos entre docenas de servidores y servicios diferentes, incluso si están en zonas horarias distintas.
- Sistemas de Archivos: La mayoría de los sistemas de archivos almacenan las fechas de creación y modificación de archivos como timestamps Unix.
Entender cómo funciona te permite depurar con confianza toda una clase de bugs complicados relacionados con el tiempo. Te permite atravesar el desordenado mundo humano de zonas horarias y calendarios, y pensar en el tiempo como lo hace una computadora: como una línea de números simple y ordenada.
Para profundizar
- Wikipedia: Tiempo Unix — El resumen exhaustivo, que cubre la historia, la mecánica y los problemas relacionados.
- MDN Web Docs: Date.now() — Explica el uso en JavaScript de timestamps Epoch con precisión de milisegundos.
- El Problema del Año 2038 — Un vistazo detallado a las causas y consecuencias del desbordamiento del entero de 32 bits.
- RFC 822: Estándar para el Formato de Mensajes de Texto de Internet de ARPA — Un documento antiguo pero fundamental que especifica formatos de fecha basados en texto, mostrando la complejidad que el tiempo Unix evita.
- Una breve historia de las zonas horarias — Contexto sobre por qué estandarizar el tiempo fue tan importante en primer lugar.