Cómo convertir marcas de tiempo Unix

Las marcas de tiempo Unix son la forma en que las computadoras almacenan y comunican el tiempo: un solo número que representa los segundos desde el 1 de enero de 1970. Aparecen en respuestas API, registros de bases de datos, archivos de log y tokens JWT. Cuando necesitas saber qué fecha es realmente 1711824000, necesitas un convertidor. Un convertidor basado en navegador maneja la matemática al instante y te permite ir en ambas direcciones (marca de tiempo a fecha, fecha a marca de tiempo).

Cómo se ve una marca de tiempo Unix

La diferencia entre segundos y milisegundos son tres ceros adicionales. Un número de 10 dígitos está en segundos; 13 dígitos es milisegundos. A partir de 2024, todas las marcas de tiempo Unix basadas en segundos son de 10 dígitos y permanecerán así hasta noviembre de 2286.

Cómo convertir marcas de tiempo

1. Introduce una marca de tiempo o fecha: pega una marca de tiempo Unix para convertirla a una fecha legible, o introduce una fecha para obtener la marca de tiempo.
2. Verifica el formato: el convertidor detecta automáticamente segundos vs milisegundos según la longitud del número.
3. Lee el resultado: ve la fecha en tu zona horaria local, UTC y formato ISO 8601.

Una breve historia del tiempo Unix

El tiempo Unix se definió por primera vez en el Manual del Programador Unix publicado en Bell Labs en noviembre de 1971. La época original era el 1 de enero de 1971, pero se cambió al 1 de enero de 1970 poco después y se estandarizó en POSIX.1 (1988).

La elección de 1970 fue arbitraria pero práctica: Unix se desarrolló en 1969-1971, y comenzar el conteo cerca del nacimiento del SO parecía razonable. Un entero con signo de 32 bits contando segundos desde 1970 dio un rango desde diciembre de 1901 hasta enero de 2038, lo que los diseñadores pensaron que sería suficiente.

No lo es. El "problema del año 2038" (también llamado Y2K38) es el momento en que las marcas de tiempo Unix con signo de 32 bits se desbordan: 2147483647 segundos después de la época, el siguiente tic se voltea a un número negativo que los sistemas interpretan como diciembre de 1901. La mayoría de los sistemas modernos migraron a marcas de tiempo enteras de 64 bits en los años 2000 y 2010, pero algunos dispositivos integrados, bases de datos más antiguas y formatos de archivos heredados todavía usan tiempo de 32 bits y necesitarán parches antes de 2038.

El tiempo Unix es ahora el estándar de facto para representar el tiempo en sistemas informáticos. APIs JSON, marcas de tiempo de filas de base de datos, expiraciones JWT, tiempos de bloque blockchain, lecturas de sensores IoT: casi todos usan la época Unix directa o indirectamente.

Segundos, milisegundos, microsegundos, nanosegundos

Diferentes sistemas usan diferentes precisiones:

• Segundos (10 dígitos en 2024): tiempo Unix clásico, estándar POSIX, la mayoría de APIs y bases de datos
• Milisegundos (13 dígitos): JavaScript Date, Java System.currentTimeMillis(), muchas APIs web
• Microsegundos (16 dígitos): PostgreSQL timestamp, Python datetime (después de la conversión)
• Nanosegundos (19 dígitos): Go time.UnixNano(), rastreo eBPF, sistemas de trading de alta frecuencia

Una marca de tiempo de 19 dígitos puede confundir a convertidores que esperan milisegundos; verifica la documentación de origen cuando veas números anómalos.

Dónde encuentras marcas de tiempo

• Respuestas API: la mayoría de las APIs REST devuelven fechas como marcas de tiempo Unix: "created_at": 1711824000
• Tokens JWT: las afirmaciones iat (emitido en) y exp (expiración) son marcas de tiempo Unix
• Registros de base de datos: muchas bases de datos almacenan marcas de tiempo como enteros para una clasificación y comparación eficientes
• Archivos de log: los logs del servidor a menudo prefijan las entradas con marcas de tiempo epoch
• Trabajos Cron: los sistemas de programación referencian el tiempo en formato Unix
• Mtime/atime/ctime del sistema de archivos: los metadatos de archivos de Linux y macOS usan tiempo Unix
• Marcas de tiempo de bloque blockchain: cada bloque de Bitcoin y Ethereum tiene una marca de tiempo Unix en su encabezado
• Cookies y encabezados HTTP: Max-Age, If-Modified-Since a menudo usan matemáticas de época indirectamente

Marcas de tiempo en código

Conversión rápida en lenguajes comunes:

JavaScript:

new Date(1711824000 * 1000)            // Desde segundos (multiplicar por 1000)
new Date(1711824000000)                // Desde milisegundos
Math.floor(Date.now() / 1000)          // Tiempo actual en segundos
Date.now()                             // Tiempo actual en milisegundos

Python:

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # Tiempo actual en segundos (float)

Bash:

date -u -d @1711824000                 # GNU date (Linux)
date -u -r 1711824000                  # BSD date (macOS)
date +%s                               # Tiempo actual en segundos

SQL (PostgreSQL):

SELECT TO_TIMESTAMP(1711824000);       -- Convertir epoch a timestamp
SELECT EXTRACT(EPOCH FROM NOW());      -- Epoch actual

Go:

time.Unix(1711824000, 0)               // Desde segundos
time.Now().Unix()                      // Tiempo actual en segundos

Manejo de zonas horarias

Aquí es donde se esconden la mayoría de los errores de marca de tiempo:

• Las marcas de tiempo Unix siempre están en UTC. No existe una marca de tiempo Unix "en hora local". El número mismo es absoluto.
• La zona horaria de visualización importa. La misma marca de tiempo 1711824000 se muestra como:
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT (Los Ángeles, UTC-7)
  • 2024-03-31 09:00:00 JST (Tokio, UTC+9)
• Las transiciones de DST son complicadas. Una hora local como "2024-03-10 02:30:00 EST" no existe (el reloj saltó de 02:00 a 03:00). Los convertidores manejan esto de manera diferente; algunos devuelven un error, algunos redondean a 03:30, algunos cambian a hora estándar.
• Los segundos intercalares se ignoran. El tiempo Unix pretende que cada minuto tiene exactamente 60 segundos. El UTC real inserta segundos intercalares ocasionalmente (el último fue en 2016). Para el 99% de los usos esto está bien; para astronomía de precisión o relojes atómicos importa.

Al enviar marcas de tiempo en APIs, usa siempre segundos UTC. Al mostrarlas a los usuarios, conviértelas a su zona horaria local. El convertidor maneja ambas direcciones.

Errores comunes

• El constructor JavaScript Date() toma milisegundos, no segundos: el error #1 de marca de tiempo. new Date(1711824000) interpreta el número como 20 de enero de 1970 porque JS lo lee como milisegundos. Necesitas new Date(1711824000 * 1000).
• Mezclar tiempo Unix y números de fecha de Excel/Google Sheets: Excel usa una época diferente (30 de diciembre de 1899) y cuenta días, no segundos. Importar una marca de tiempo Unix en una columna de fecha mostrará la fecha incorrecta.
• Marcas de tiempo negativas: las fechas anteriores al 1 de enero de 1970 se representan como marcas de tiempo Unix negativas. Algunos convertidores y bases de datos las rechazan; otros las manejan correctamente.
• Año 2038 en código heredado: las marcas de tiempo enteras con signo de 32 bits se desbordan el 19 de enero de 2038 a las 03:14:07 UTC. La mayoría de los sistemas modernos usan 64 bits, pero verifica los dispositivos integrados, las bases de datos SQLite antiguas y los sistemas operativos de 32 bits.
• Análisis de fecha dependiente del idioma: "03/04/2024" es 4 de marzo en inglés estadounidense, 3 de abril en inglés británico. Siempre pasa marcas de tiempo (o cadenas ISO 8601) entre sistemas; nunca cadenas formateadas por idioma.
• Pérdida de precisión sub-segundo: almacenar una marca de tiempo en milisegundos en un campo de precisión de segundos pierde los últimos 3 dígitos. Algunas APIs devuelven ambos formatos (created_at en segundos, created_at_ms en milisegundos) para evitar esto.

Consejos

• Multiplica por 1000 para JavaScript: JS Date espera milisegundos, pero la mayoría de las APIs devuelven segundos. Olvidar multiplicar es el error de marca de tiempo más común.
• Siempre especifica UTC: al convertir, sé explícito sobre la zona horaria. "31 de marzo a medianoche" es una marca de tiempo diferente dependiendo de si te refieres a UTC, EST o PST.
• Usa ISO 8601 para visualización: una vez convertido, formatea las fechas como 2024-03-31T00:00:00Z para una comunicación inequívoca entre zonas horarias.
• Marca el convertidor como favorito: si trabajas con APIs o bases de datos, convertirás marcas de tiempo lo suficientemente a menudo como para quererlo a un clic.
• Ida y vuelta para verificar: en caso de duda, convierte tu marca de tiempo a una fecha, luego convierte la fecha de vuelta a una marca de tiempo. Si obtienes el mismo número, tu comprensión es correcta.
• Observa el número de dígitos: 10 = segundos, 13 = milisegundos, 16 = microsegundos, 19 = nanosegundos. Si tu matemática está desfasada por un factor de 1000 o 1000000, tienes una discrepancia de precisión.

Privacidad

El convertidor de marca de tiempo Unix se ejecuta completamente en tu navegador. Las marcas de tiempo y fechas que introduces nunca abandonan tu dispositivo. Esto importa porque las marcas de tiempo pueden ser sensibles: pueden ser de archivos de log que revelan tiempos de infraestructura interna, tokens JWT con información de usuario/sesión incrustada, depuración interna de API que no debería compartirse con terceros. Los convertidores de marca de tiempo en la nube pueden registrar entradas con fines de "mejora"; un convertidor solo en navegador tiene cero exposición.

La conversión basada en navegador también funciona sin conexión una vez cargada la página, y es lo suficientemente rápida para que puedas soltar una marca de tiempo en el campo y ver la fecha en el mismo momento.