¿Qué es un timestamp Unix y por qué lo usan tantos sistemas?

Exportas los pedidos de tu tienda o revisas la respuesta de una API y, donde esperabas una fecha, encuentras un número como 1700000000. No es un error ni un código interno: es una fecha, escrita de la forma que prefieren los ordenadores.

Ese número se llama timestamp Unix (o marca de tiempo Unix), y está detrás de casi todos los sistemas con los que trabaja una empresa: bases de datos, pasarelas de pago, CRM, registros de servidor. Entender cómo funciona ahorra muchos de los errores más tontos y más caros de cualquier integración, los que hacen que un pedido aparezca con fecha de 1970 o que una cita se mueva cinco horas.

La época Unix: contar segundos desde un punto fijo

Un timestamp Unix es el número de segundos transcurridos desde el inicio de 1970, a medianoche en UTC. Ese instante cero se llama la «época Unix». Lo eligieron los creadores del sistema operativo Unix como punto de partida redondo y cercano, y se quedó.

1700000000 son mil setecientos millones de segundos después de ese instante, que en formato legible es 2023-11-14T22:13:20Z. Cada segundo que pasa, el número sube en uno.

¿Por qué usar un número en lugar de una fecha escrita? Por tres razones prácticas:

• No depende del idioma ni del formato. No hay que decidir si va primero el día o el mes, ni cómo se llaman los meses.
• No lleva zona horaria. El mismo número es el mismo instante en Bogotá, en Madrid y en Tokio. La zona solo aparece al mostrarlo.
• Se calcula fácil. Saber cuánto pasó entre dos momentos es una resta. Sumar un día es sumar 86 400.

Un detalle técnico: el tiempo Unix ignora los segundos intercalares. Para él, todos los días duran exactamente 86 400 segundos. En la práctica de una empresa no tiene ningún efecto, pero explica por qué dos relojes muy precisos pueden diferir en algún segundo.

Segundos, milisegundos y más

No todos los sistemas cuentan en segundos. Muchos usan unidades más pequeñas, y la forma rápida de saber cuál es contar los dígitos:

Dígitos (fechas actuales)	Unidad	Dónde aparece
10	Segundos	El estándar clásico: PHP, muchas bases de datos y APIs
13	Milisegundos	JavaScript, Java, muchas APIs web
16	Microsegundos	Algunas bases de datos y registros
19	Nanosegundos	Go, sistemas de medición de alta precisión

Equivocarse de unidad no da un error: da una fecha absurda. Si lees milisegundos como si fueran segundos, el resultado cae decenas de miles de años en el futuro. Si lees segundos como milisegundos, la fecha queda clavada en los primeros días de 1970. Cuando veas un pedido con fecha de 1970 en un informe, la causa casi siempre es esta.

UTC, zonas horarias y desfases

UTC (tiempo universal coordinado) es la referencia contra la que se miden todas las zonas horarias. Colombia está a UTC−5 todo el año. España peninsular está a UTC+1 en invierno y a UTC+2 en verano.

Esa última frase contiene la distinción que más confusiones evita: un desfase no es una zona horaria. -05:00 es un desfase: un número de horas respecto a UTC. America/Bogota es una zona: un lugar, con su historia de cambios de hora. Si guardas solo el desfase, sabes qué hora era en ese momento, pero no puedes calcular bien qué hora será allí dentro de seis meses, porque no sabes si ese sitio cambia de hora.

Las reglas de cada zona viven en la base de datos de zonas horarias de la IANA, que mantienen voluntarios y se actualiza varias veces al año porque los gobiernos cambian sus horarios. Los sistemas operativos y los navegadores la traen incorporada.

La regla práctica para cualquier sistema: guarda los instantes en UTC (o como timestamp) y conviértelos a la zona del usuario solo al mostrarlos.

ISO 8601: la forma legible de decir lo mismo

Cuando una fecha tiene que leerla también una persona, o viajar en un archivo CSV o en una API, el formato recomendable es ISO 8601:

2025-03-15T14:30:00Z o 2025-03-15T09:30:00-05:00

Año, mes y día, la letra T, la hora, y al final la zona: Z para UTC o el desfase explícito. Las dos líneas del ejemplo son el mismo instante. Tiene dos ventajas sobre cualquier otro formato escrito: no es ambiguo (nadie duda de si 03 es el día o el mes) y se ordena alfabéticamente en el mismo orden que cronológicamente, lo que lo hace cómodo en nombres de archivo y hojas de cálculo.

El problema del año 2038

Durante décadas, muchos sistemas guardaron el timestamp en un entero de 32 bits con signo. El número más alto que cabe ahí es 2147483647, que corresponde a un momento de 2038. Un segundo después, el contador se desborda, pasa a ser negativo y la fecha salta a 1901.

Es primo del famoso efecto 2000, con una diferencia: aquí el límite no está en cómo se escribe el año sino en el tamaño del número. Los sistemas modernos de 64 bits no tienen el problema (su límite está a miles de millones de años). Pero siguen existiendo dispositivos empotrados, equipos industriales, bases de datos antiguas y formatos de archivo con campos de 32 bits. El tipo TIMESTAMP de MySQL, por ejemplo, no admite fechas posteriores a 2038.

Y no hace falta esperar a 2038 para encontrárselo: cualquier sistema que calcule fechas futuras, como el vencimiento de un crédito a quince años, una garantía larga o una suscripción plurianual, ya puede estar tropezando con ese límite.

Los errores que aparecen al conectar sistemas

• Mezclar unidades. Un sistema manda milisegundos y el otro espera segundos. Resultado: fechas en 1970 o en el año cincuenta mil.
• Fechas sin zona. Un campo como 2025-03-15 09:30:00, sin Z ni desfase, se interpreta en la zona del servidor que lo lee. Al migrar a un servidor configurado en otra zona, todas las horas se mueven.
• Fechas sin hora que cambian de día. Una fecha suelta se interpreta a menudo como medianoche UTC, y en cualquier zona al oeste de Greenwich esa medianoche todavía es el día anterior. Por eso un cumpleaños o una fecha de entrega aparece un día antes.
• Día y mes intercambiados. 03/04 es el día 3 del mes 4 en un sistema y el día 4 del mes 3 en otro. En una importación de CSV pasa sin ningún aviso hasta que llega el día 13.
• Horarios de verano. «Cada 24 horas» y «todos los días a las 9:00 hora local» no son lo mismo en una zona con cambio de hora. Lo mismo pasa al programar tareas: la zona del servidor decide cuándo se ejecutan, como contamos en qué es una expresión cron.
• Relojes desincronizados. Si los servidores no sincronizan su hora con un servicio de tiempo, sus timestamps no coinciden, y los registros de dos sistemas no se pueden comparar.

¿Cómo convertir el tuyo?

El conversor de fechas acepta lo que tengas a mano: un timestamp de diez o trece dígitos, una fecha en ISO 8601 o una escrita con barras. Detecta si el número está en segundos, milisegundos, microsegundos o nanosegundos y te dice qué ha supuesto. Eliges la zona en la que interpretarlo y te devuelve la misma fecha en ISO 8601, en UTC, en RFC 2822, en formato SQL y escrita en palabras, junto al día de la semana, la semana ISO y cuánto tiempo hace. Puedes ver el mismo instante en varias zonas horarias a la vez, y avisa cuando una fecha con barras podría leerse al revés en otro sistema.

Cuando una integración muestra una fecha que no cuadra, pegar el valor original ahí suele bastar para ver si el problema es la unidad, la zona o el formato.

---

Un timestamp Unix es solo un contador de segundos, y por eso es tan fiable: no tiene idioma, ni formato, ni zona. Los problemas aparecen al convertirlo en algo legible. Guardar en UTC, intercambiar en ISO 8601 y comprobar siempre la unidad cubre la mayoría de los casos.