Unix timestamp: cómo funciona el tiempo en los ordenadores

Detrás de cada fecha que guarda un servidor, una base de datos o un archivo de log suele haber un número como 1791417600. Es un timestamp Unix: los segundos transcurridos desde el 1 de enero de 1970 a medianoche UTC. Es la forma más sencilla de representar un instante sin ambigüedades de formato ni de zona horaria. En esta guía explicamos cómo funciona, cómo convertirlo, los errores más comunes y la sintaxis básica de cron para programar tareas.

Qué es el tiempo Unix

• Epoch: 1970-01-01 00:00:00 UTC = 0.
• Cada segundo suma 1. Las fechas anteriores a 1970 son negativas.
• Ignora los segundos intercalares: todos los días tienen exactamente 86 400 segundos.
• No tiene zona horaria: el mismo instante tiene el mismo timestamp en Madrid y en Lima.

Ejemplo: 1791417600 corresponde al 8 de octubre de 2026 a las 00:00:00 UTC, que son las 02:00 en Madrid (horario de verano) y las 19:00 del 7 de octubre en Bogotá.

Puedes convertir cualquier valor con el convertidor de timestamp.

Segundos frente a milisegundos

El error más común: interpretar milisegundos como segundos (una fecha en torno al año 58 700) o segundos como milisegundos (fecha en enero de 1970). Si ves “1970” en una fecha, sospecha de esto.

Conversiones en código

// JavaScript (milisegundos)
const ahora = Math.floor(Date.now() / 1000);       // a segundos
const fecha = new Date(1791417600 * 1000);         // de segundos a Date
fecha.toISOString();                               // "2026-10-08T00:00:00.000Z"
fecha.toLocaleString('es-ES', { timeZone: 'Europe/Madrid' });

# Python
from datetime import datetime, timezone
datetime.fromtimestamp(1791417600, tz=timezone.utc)  # 2026-10-08 00:00:00+00:00
int(datetime.now(tz=timezone.utc).timestamp())

-- MySQL
SELECT FROM_UNIXTIME(1791417600);
SELECT UNIX_TIMESTAMP('2026-10-08 00:00:00');

date -d @1791417600        # Linux
date -r 1791417600         # macOS

Zonas horarias: dónde aparecen los errores

El timestamp es siempre UTC, pero convertirlo a fecha legible requiere una zona:

• FROM_UNIXTIME en MySQL usa la zona de la sesión del servidor.
• new Date() en el navegador usa la zona del usuario.
• Un servidor en UTC y otro en Europe/Madrid mostrarán horas distintas para el mismo valor.

Buena práctica: guardar en UTC (timestamp o ISO 8601 con Z) y convertir a la zona del usuario solo al mostrar. La guía de zonas horarias explica los desfases y el horario de verano.

El problema del año 2038

Muchos sistemas antiguos guardaban el timestamp en un entero con signo de 32 bits, cuyo máximo es 2 147 483 647. Ese valor corresponde al 19 de enero de 2038 a las 03:14:07 UTC. Un segundo después, el contador se desborda y salta a 1901.

Los sistemas operativos y lenguajes modernos usan 64 bits, que alcanzan para miles de millones de años. El riesgo está en sistemas embebidos, bases de datos con columnas INT de 32 bits (por ejemplo, TIMESTAMP de MySQL tiene ese límite) y formatos de archivo antiguos.

Contar días y duraciones

Con timestamps en segundos, la diferencia entre dos instantes es una resta:

Días = (t2 − t1) / 86 400

Cuidado con los días de cambio de hora: en hora local un día puede tener 23 o 25 horas. Para contar días de calendario, usa fechas, no segundos; la calculadora de días entre fechas lo hace correctamente.

Cron: programar tareas

Cron es el planificador de tareas de los sistemas Unix. Una expresión cron tiene cinco campos:

┌──────── minuto (0–59)
│ ┌────── hora (0–23)
│ │ ┌──── día del mes (1–31)
│ │ │ ┌── mes (1–12)
│ │ │ │ ┌ día de la semana (0–6, 0 = domingo)
│ │ │ │ │
* * * * *  comando

Atención:

• Cron usa la zona horaria del servidor. Una tarea a las 02:30 puede no ejecutarse (o ejecutarse dos veces) el día del cambio de hora.
• Si indicas día del mes y día de la semana, la tarea se ejecuta cuando se cumple cualquiera de los dos.
• Algunos servicios (GitHub Actions, Kubernetes) siempre interpretan cron en UTC.

El generador de cron traduce expresiones a lenguaje natural y muestra las próximas ejecuciones.

Timestamps en APIs y bases de datos

Al diseñar una API o una tabla, hay dos opciones razonables para guardar fechas:

Lo importante es elegir una y documentarla, incluida la unidad (segundos o milisegundos). En PostgreSQL, el tipo timestamptz guarda el instante en UTC y lo convierte según la zona de la sesión; en MySQL, DATETIME no guarda zona y TIMESTAMP sí convierte, pero tiene el límite de 2038.

Resumen

• El timestamp Unix cuenta segundos desde 1970 en UTC.
• 10 dígitos = segundos; 13 = milisegundos.
• Guarda en UTC y convierte al mostrar.
• Revisa columnas de 32 bits antes de 2038.
• En cron, ten presente la zona del servidor y el cambio de hora.