Marcas de Tiempo Unix Explicadas: Conversión y Errores Comunes

Una marca de tiempo Unix es uno de los conceptos más simples pero más incomprendidos en programación. Es el número de segundos que han transcurrido desde el 1 de enero de 1970, 00:00:00 UTC — un momento conocido como el epoch Unix. A pesar de su simplicidad, las marcas de tiempo son fuente de errores relacionados con zonas horarias, precisión y desbordamiento.

¿Qué Es el Epoch Unix?

El epoch Unix — 1 de enero de 1970, 00:00:00 UTC — fue elegido como el punto de partida para el tiempo Unix. Cada marca de tiempo se mide relativa a este momento:

Las marcas de tiempo negativas representan fechas anteriores al epoch. Por ejemplo, -86400 es el 31 de diciembre de 1969.

Convierte marcas de tiempo instantáneamente con nuestro Conversor de Timestamps.

Segundos vs. Milisegundos

Esta es la fuente de confusión más común. Diferentes sistemas usan diferentes precisiones:

Regla práctica: Si el número tiene 13 dígitos, son milisegundos. Si tiene 10 dígitos, son segundos.

// JavaScript returns milliseconds
const nowMs = Date.now();          // 1700000000000
const nowSec = Math.floor(nowMs / 1000);  // 1700000000

Manejo de Zonas Horarias

Las marcas de tiempo Unix son siempre UTC. No contienen información de zona horaria. Esto es en realidad una ventaja — proporciona un punto de referencia universal.

La confusión surge al convertir marcas de tiempo a fechas legibles para humanos:

const ts = 1700000000;
const date = new Date(ts * 1000);

date.toUTCString();      // "Tue, 14 Nov 2023 22:13:20 GMT"
date.toLocaleString();    // Depends on user's local time zone
date.toISOString();       // "2023-11-14T22:13:20.000Z"

Mejor práctica: Almacena y transmite marcas de tiempo en UTC. Convierte a hora local solo en la capa de visualización, lo más cerca posible del usuario.

El Problema del Año 2038

Los sistemas Unix tradicionales almacenan marcas de tiempo como un entero con signo de 32 bits. El valor máximo es 2,147,483,647, que corresponde al 19 de enero de 2038, 03:14:07 UTC.

Después de este momento, las marcas de tiempo de 32 bits desbordan a valores negativos, volviendo al 13 de diciembre de 1901. Esto es análogo al error Y2K.

Estado actual:

• La mayoría de los sistemas modernos usan marcas de tiempo de 64 bits (válidas hasta el año 292 mil millones)
• El kernel de Linux ha sido compatible con marcas de tiempo de 64 bits desde la versión 5.6 (2020)
• Los sistemas embebidos y las bases de datos heredadas siguen en riesgo
• Si estás construyendo software que maneja fechas más allá de 2038, verifica tu almacenamiento de marcas de tiempo

Conversión en Diferentes Lenguajes

JavaScript

// Current timestamp (seconds)
const now = Math.floor(Date.now() / 1000);

// Timestamp to Date
const date = new Date(1700000000 * 1000);

// Date to timestamp
const ts = Math.floor(new Date('2023-11-14').getTime() / 1000);

Python

import time, datetime

# Current timestamp
now = int(time.time())

# Timestamp to datetime
dt = datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc)

# Datetime to timestamp
ts = int(dt.timestamp())

SQL (PostgreSQL)

-- Current timestamp
SELECT EXTRACT(EPOCH FROM NOW());

-- Timestamp to date
SELECT TO_TIMESTAMP(1700000000);

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM '2023-11-14'::timestamp);

Errores Comunes

1. Mezclar Segundos y Milisegundos

Si una fecha muestra enero de 1970, probablemente pasaste segundos donde se esperaban milisegundos (o viceversa). Siempre verifica qué precisión espera la API.

2. Ignorar Zonas Horarias en Cadenas de Fecha

Parsear "2023-11-14" sin zona horaria crea la fecha en la zona horaria local, que varía según la ubicación del servidor. Siempre incluye la zona horaria: "2023-11-14T00:00:00Z".

3. Precisión de Punto Flotante

Al almacenar marcas de tiempo como números de punto flotante, puedes perder precisión más allá de milisegundos. Para precisión de microsegundos o nanosegundos, usa enteros con el multiplicador apropiado.

4. Segundos Intercalares

Las marcas de tiempo Unix no tienen en cuenta los segundos intercalares. Un día Unix siempre es exactamente 86,400 segundos, aunque los días UTC reales ocasionalmente tienen 86,401 segundos. Para la mayoría de las aplicaciones, esto es irrelevante. Para aplicaciones científicas o satelitales, usa TAI (Tiempo Atómico Internacional) en su lugar.

ISO 8601: La Alternativa Legible para Humanos

Mientras que las marcas de tiempo son excelentes para cálculos, ISO 8601 es el estándar para la representación de fechas legible para humanos:

2023-11-14T22:13:20Z          # UTC
2023-11-14T17:13:20-05:00     # Eastern Time
2023-11-14                     # Date only

La mayoría de las APIs deberían aceptar y devolver cadenas ISO 8601. Usa marcas de tiempo internamente para cálculos y almacenamiento.

Preguntas Frecuentes

¿Por qué el tiempo Unix comienza el 1 de enero de 1970?

La fecha fue elegida arbitrariamente cuando Unix se estaba desarrollando en Bell Labs a principios de los años 70. Se necesitaba una fecha lo suficientemente reciente para evitar desperdiciar bits en fechas del pasado lejano. Dado que los enteros de 32 bits pueden almacenar aproximadamente 68 años en cada dirección, comenzar en 1970 cubría fechas desde 1901 hasta 2038.

¿Debería almacenar fechas como marcas de tiempo o cadenas formateadas en mi base de datos?

Almacena fechas como marcas de tiempo (enteros o tipos datetime nativos) para ordenación, comparación y aritmética eficientes. Las cadenas formateadas son más difíciles de consultar y ordenar correctamente. La mayoría de las bases de datos tienen tipos datetime nativos que manejan esto bien. Reserva el formateo de cadenas para visualización y respuestas de API.

Recursos Relacionados

• Conversor de Timestamps — Convierte entre marcas de tiempo Unix y fechas legibles
• Mejores Prácticas de Formateo JSON — Manejo de fechas en respuestas JSON
• Guía de UUID — Otro formato común de identificador con variantes basadas en tiempo