Marcas de tiempo Unix Cómo convertir y por qué están en todas partes

Una marca de tiempo Unix es el número de segundos transcurridos desde el 1 de enero de 1970, 00:00:00 UTC — también conocida como el epoch de Unix. Esa fecha no fue elegida por razones técnicas; simplemente era el año actual cuando se diseñó Unix. El epoch siempre es UTC, lo que significa que una marca de tiempo como 1712800000 significa el mismo momento en todo el planeta, independientemente del horario local.

Las marcas de tiempo Unix se utilizan en todos lados: encabezados HTTP, tokens JWT, registros de bases de datos, archivos de log, colas de mensajes y respuestas de APIs. Si estás desarrollando o depurando algo que involucre tiempo, las verás constantemente. El Conversor de marca de tiempo Unix IO Tools es útil para búsquedas rápidas, pero también necesitas saber cómo manejarlas en el código.

Segundos vs Milisegundos: El error que afecta a todos

El error de marca de tiempo más común en producción: mezclar segundos y milisegundos. El estándar Unix utiliza segundos. JavaScript’s Date.now() devuelve milisegundos. Así lo hace también Java’s System.currentTimeMillis().

Una marca de tiempo de 1712800000 es abril de 2024. Una marca de tiempo de 1712800000000 (milisegundos) corresponde a un año de 56.000 algo. Si tus cálculos de fechas producen fechas décadas en el futuro o muestran 1970-01-01, esto es casi siempre la causa.

Regla general: si la marca de tiempo tiene 13 dígitos, es milisegundos. Si tiene 10 dígitos, es segundos. Si no estás seguro, divide entre 1000 y verifica si el resultado tiene sentido.

Conversión de marcas de tiempo por lenguaje

Aquí están los patrones que usarás realmente:

JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

Pitón

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

SQL (MySQL / MariaDB)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

Tabla de Referencia Rápida

Trampas de zona horaria

Las marcas de tiempo Unix siempre son UTC. Siempre. El número 1712800000 no tiene zona horaria — simplemente cuenta los segundos desde el epoch. La zona horaria es un asunto de visualización, no de almacenamiento.

Dónde los desarrolladores se quedan atrapados:

• Python’s datetime.fromtimestamp(ts) sin tz=timezone.utc — utiliza la zona horaria local del servidor, silenciosamente. Usa fromtimestamp(ts, tz=timezone.utc) en cambio.
• MySQL’s FROM_UNIXTIME() — convierte a la configuración de zona horaria del servidor MySQL (@@session.time_zone). Si tu servidor está en UTC+8, el resultado se desplaza en 8 horas.
• Almacenar datetime en MySQL sin normalización UTC — si tu servidor de aplicación y tu servidor de base de datos están en zonas horarias diferentes, cada inserción o lectura es un error esperado.

El patrón que evita todo esto: almacenar marcas de tiempo Unix en la base de datos, convertirlas a formato legible para humanos en la capa de aplicación al momento de mostrar, usando la zona horaria preferida del usuario.

Marcas de tiempo vs cadenas ISO 8601: Qué almacenar

Ambos son formatos válidos para almacenamiento. Las ventajas y desventajas:

• Marca de tiempo Unix (entero): compacta, rápida para comparaciones y cálculos, sin ambigüedad de zona horaria, funciona en todos los motores de base de datos. Inconveniente: no es legible para humanos sin una herramienta.
• Cadena ISO 8601 (por ejemplo, 2024-04-11T02:13:20Z): legible para humanos en la base de datos, auto-documentada. Inconveniente: más lenta para consultas por rango, la zona horaria puede ser omitida o incorrecta.

Para la mayoría de las aplicaciones: almacena las marcas de tiempo como enteros. Usa cadenas ISO 8601 en APIs y registros cuando la legibilidad para humanos es importante. Si debes almacenar cadenas ISO 8601, siempre incluye la Z o el desplazamiento explícito — una cadena sin zona horaria es un desastre en sistemas distribuidos. 2024-04-11 02:13:20 El problema de 2038

Los enteros firmados de 32 bits pueden almacenar un valor máximo de

, que corresponde al 1 de enero de 2038, 03:14:07 UTC. Los sistemas que almacenan marcas de tiempo Unix en un entero de 32 bits 2147483647sobrepasarán ese momento — retrocediendo a 1901 o cayendo. int ¿Deberías preocuparte? Si estás escribiendo código nuevo, no — utiliza enteros de 64 bits. Si estás manteniendo código C antiguo, firmware embebido o esquemas de MySQL antiguos usando

para marcas de tiempo, vale la pena auditar. El tipo INT(11) de MySQL también está afectado; TIMESTAMP no lo está. Los sistemas modernos que utilizan marcas de tiempo de 64 bits son seguros hasta el año 292 mil millones. DATETIME ¿Necesitas convertir marcas de tiempo rápidamente sin escribir código? El

Conversor de marca de tiempo Unix en IO Tools maneja segundos y milisegundos, muestra la hora UTC y local al mismo tiempo y te permite pegar una fecha para obtener la marca de tiempo. Marcas de tiempo Unix: Cómo convertirlas y por qué están por todas partes 1

También te puede interesar

Nuevo

Color Accessibility for Developers: Contrast, Blindness Simulation, and Fixing Issues

Leer más "

Publicado el May 7, 2026

Nuevo

WebP vs AVIF vs PNG vs JPEG: Choosing Image Formats for the Web

Leer más "

Publicado el May 6, 2026

Nuevo

Calculadora de permisos de Unix: Permisos de archivos Unix sin memorizar octal

Leer más "

Publicado el 5 de mayo de 2026

Nuevo

Diferencia de texto sin Git: Revisar los cambios en los archivos y cadenas

Leer más "

Publicado el 4 de mayo de 2026