Timestamp Unix

El timestamp Unix (también llamado tiempo POSIX o Unix time) es el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC, conocido como la “época Unix”. Es la representación de fecha y hora más extendida en programación: bases de datos, APIs REST, logs de servidores y sistemas de archivos lo usan porque es un entero simple, no depende de la zona horaria del usuario y dos timestamps se comparan directamente con < o >.

De timestamp a fecha legible

Convertir un timestamp en fecha y hora implica:

1. Dividir los segundos entre 86.400 para obtener los días desde el 1/1/1970.
2. Calcular el año, mes y día a partir de ese número de días, teniendo en cuenta años bisiestos.
3. El resto (mod 86.400) se divide sucesivamente entre 3.600 (horas), 60 (minutos) y lo que sobra son los segundos.

En la práctica nadie hace esto a mano: las funciones de cada lenguaje lo resuelven en una línea.

Tabla de referencia:

Cómo obtener el timestamp actual por lenguaje

• JavaScript (navegador): Math.floor(Date.now() / 1000) — Date.now() devuelve milisegundos; dividir entre 1.000 da segundos.
• Python: import time; int(time.time())
• Bash / Linux: date +%s
• SQL (PostgreSQL): EXTRACT(EPOCH FROM NOW())
• PHP: time()
• Excel / Google Sheets: no tiene soporte nativo. Usa =(A1/86400)+DATE(1970,1,1) para convertir un timestamp (en segundos) de A1 a una fecha Excel; formatea la celda como fecha. Ajusta la zona horaria restando o sumando las horas de diferencia con UTC.

Milisegundos vs. segundos

Muchas APIs modernas (JavaScript, MongoDB, Stripe, muchos endpoints REST) usan milisegundos en lugar de segundos:

• Timestamp en segundos: 1752321600
• Timestamp en milisegundos: 1752321600000

Para distinguirlos, fíjate en la magnitud: un timestamp de 10 dígitos es en segundos; uno de 13 dígitos es en milisegundos. Para convertir de milisegundos a segundos, divide entre 1.000 (o usa Math.flooren JavaScript para descartar la parte decimal).

El problema del año 2038

Los sistemas que almacenan el timestamp como un entero de 32 bits con signo (signed int32) tienen un límite máximo de 2.147.483.647, que equivale al 19 de enero de 2038 a las 03:14:07 UTC. Pasado ese instante, el contador se desborda y retrocede al valor más negativo, interpretado como el 13 de diciembre de 1901.

Los sistemas y lenguajes modernos (Linux de 64 bits, Python, Java, bases de datos actualizadas) ya usan int64, cuyo límite superior es el año 292.277.026.596: no es un problema práctico. El riesgo real está en:

• Sistemas embebidos: routers, PLCs, contadores inteligentes y equipos industriales que usan int32 y no se actualizan.
• Bases de datos legacy: columnas de tipo INT de 32 bits en MySQL o SQL Server antiguo que almacenan timestamps.
• Software SCADA y sistemas críticos de infraestructura con ciclos de vida de décadas.

Si diseñas un sistema nuevo, usa siempre tipos de 64 bits (BIGINT en SQL, long en Java, int64_t en C).

Zona horaria y UTC

El timestamp Unix es siempre en UTC; no lleva información de zona horaria. La conversión a hora local la realiza el sistema operativo o la aplicación según la configuración del dispositivo. Si almacenas timestamps en una base de datos, guárdalos siempre en UTC y convierte a hora local solo en la capa de presentación para evitar errores en aplicaciones usadas desde múltiples países o durante cambios de horario de verano/invierno.

Para convertir entre zonas horarias, combina el timestamp con la zona horaria correspondiente. Para calcular diferencias entre dos momentos, convierte ambos a timestamps Unix y resta: el resultado son los segundos exactos entre los dos instantes, independientemente de los cambios de horario intermedios.