Conversor de Marcas de Tiempo Unix
Analice, convierta y calcule marcas de tiempo Unix epoch en precisiones de segundos (10 dígitos), milisegundos (13 dígitos), microsegundos (16 dígitos) y nanosegundos (19 dígitos). Salidas sincronizadas en UTC, ISO 8601, RFC 2822 y hora local del dispositivo.
| Resolución | Valor | Acción |
|---|---|---|
| Segundos (s) | 1791389502 | |
| Milisegundos (ms) | 1791389502000 | |
| Microsegundos (μs) | 1791389502000000 | |
| Nanosegundos (ns) | 1791389502000000000 | |
| Segundos Unix en hexadecimal | 0x6AC66F3E |
Cómo utilizar el conversor
- Timestamp a fecha: Ingrese cualquier entero epoch. El conversor identifica automáticamente la resolución por número de dígitos y genera las representaciones en UTC, hora local, ISO 8601 y desfase relativo.
- Fecha a timestamp: En la pestaña Fecha → Timestamp, seleccione la fecha, la hora y el modo de zona horaria (Local, UTC o desfase específico) para obtener los valores en segundos y milisegundos.
- Aritmética de tiempo y TTL: Utilice la pestaña Aritmética y TTL para sumar o restar intervalos temporales (de segundos a años) respecto a una marca de tiempo base para planificar la expiración de tokens (
exp) o políticas de caché. - Procesamiento por lotes: En la pestaña Conversor por lotes, pegue registros de servidores o listas de timestamps para tabular los resultados y exportarlos en formato CSV estructurado.
Precisión de marcas de tiempo: el estándar de 10, 13, 16 y 19 dígitos
Los distintos entornos y lenguajes de programación emplean niveles de precisión variados. Identificar la cantidad de dígitos evita el frecuente error de discrepancia de factor 1.000x al intercambiar datos temporales entre sistemas distribuidos.
| Resolución | Dígitos | Ejemplo | Rango temporal | Ecosistema estándar |
|---|---|---|---|---|
| Segundos (s) | 10 dígitos | 1757419200 | 1970 – 2286 | POSIX time_t, Python time.time(), Go time.Now().Unix(), PHP time(), Linux date +%s |
| Milisegundos (ms) | 13 dígitos | 1757419200000 | 1970 – 5138 | JavaScript Date.now(), Java System.currentTimeMillis(), Go time.Now().UnixMilli(), MongoDB ObjectId |
| Microsegundos (μs) | 16 dígitos | 1757419200000000 | 1970 – 51380 | Python time.time_ns() // 1000, PostgreSQL TIMESTAMP, C++ std::chrono::microseconds |
| Nanosegundos (ns) | 19 dígitos | 1757419200000000000 | 1970 – 2262 (con signo de 64 bits) | Go time.Now().UnixNano(), Linux clock_gettime(CLOCK_REALTIME), OpenTelemetry, Jaeger |
La trampa de escala 1.000x en entornos de producción
Transmitir un valor en milisegundos (1757419200000) a una API que espera segundos proyecta la fecha hasta más allá del año 57.000. Por el contrario, suministrar segundos (1757419200) a la instrucción new Date(timestamp) de JavaScript hace que se interprete como milisegundos, colapsando la fecha al 21 de enero de 1970. Compruebe siempre la longitud numérica antes de realizar conversiones.
Arquitectura del tiempo POSIX: el estándar de 86.400 segundos
Exclusión de segundos intercalares
La especificación IEEE POSIX.1 estipula que cada día del calendario contiene rigurosamente 86.400 segundos:
Debido a que el tiempo UTC añade segundos intercalares para compensar las irregularidades en la rotación terrestre, el tiempo Unix no es estrictamente equivalente al Tiempo Atómico Internacional (TAI). Cuando ocurre un segundo intercalar oficial (como las 23:59:60 UTC), el tiempo POSIX repite el segundo 86.399, lo que implica que la secuencia de marcas de tiempo no es monotónica durante esa transición.
Difuminado de segundos (Leap Smearing) en la nube
Los saltos bruscos de reloj ocasionados por segundos intercalares introducen riesgos de condiciones de carrera, claves duplicadas en bases de datos y fallos en bloqueos distribuidos. Los principales proveedores en la nube (como AWS Time Sync y Google Public NTP) neutralizan este problema mediante la técnica de Leap Smearing.
En lugar de alterar el reloj en un segundo de golpe, los servidores NTP ajustan de forma gradual la frecuencia del reloj en aproximadamente 11,57 partes por millón durante una ventana de 24 horas (12 horas antes y 12 horas después del evento), preservando la monotonicidad para los procesos de software sin interrumpir las operaciones del sistema.
Comparativa de almacenamiento en bases de datos: Entero Epoch vs Cadena vs Timestamp nativo
La elección entre enteros epoch, cadenas formateadas en ISO 8601 y tipos de datos temporales nativos repercute en el consumo de índices, el rendimiento de ordenación y la precisión de husos horarios.
| Estrategia | Tipo en BD | Tamaño | Indexación B-Tree | Uso recomendado en producción |
|---|---|---|---|---|
| Segundos Unix (INT) | INT / INTEGER (Con signo, 32 bits) | 4 Bytes | El más rápido (comparación numérica entera de 32 bits) | Telemetría de alta frecuencia, claves Redis, TTL de caché (Atención: límite de desbordamiento en el año 2038) |
| Milisegundos Unix (BIGINT) | BIGINT (Con signo, 64 bits) | 8 Bytes | Extremadamente rápido (comparación en registros de CPU de 64 bits) | Offsets en Apache Kafka, flujos de eventos distribuidos, pipelines de Event Sourcing políglotas |
| Timestamp Nativo de BD | TIMESTAMPTZ (PostgreSQL) / DATETIME(6) (MySQL) | 8 Bytes | Rápido (estructura de árbol B-Tree binario optimizado) | Entidades de negocio relacionales con operaciones de calendario, agrupación por mes/día y cambios de horario |
| Cadena ISO 8601 | VARCHAR(24-35) / TEXT | 24–35 Bytes | Lento (comparación lexicográfica de cadenas) | Cargas útiles REST/GraphQL públicas, registros JSON y auditorías donde se requiere legibilidad directa sin procesar |
El problema del año 2038 (Y2038): Mecánica del desbordamiento de bits
Límite de enteros de 32 bits con signo
En sistemas basados en C de 32 bits, el tipo time_t se define como un entero con signo de 32 bits. Su valor positivo máximo alcanzable es 2.147.483.647 (0x7FFFFFFF), el cual se registrará el 19 de enero de 2038 a las 03:14:07 UTC.
Sumar un segundo adicional invierte el bit de signo a 0x80000000, desbordando el entero a -2.147.483.648 en notación de complemento a dos. El software heredado interpretará este instante como el 13 de diciembre de 1901 a las 20:45:52 UTC, provocando errores lógicos graves en proyecciones bancarias, certificados SSL y tareas programadas.
Mitigación e inmunidad de arquitecturas de 64 bits
Los sistemas de 64 bits emplean un tipo time_t de 8 bytes con un límite superior de 9.223.372.036.854.775.807 segundos (~292.000 millones de años).
Los focos de vulnerabilidad subsisten principalmente en sistemas legados: tablas MySQL configuradas con el tipo de datos TIMESTAMP de 32 bits (cuyo tope infranqueable es 2038), dispositivos embebidos con Linux de 32 bits, binarios compilados sin el parámetro -D_TIME_BITS=64 y protocolos de red binarios basados en campos fijos de 4 bytes.
Hitos históricos y futuros de la época Unix
| Segundos Epoch | Fecha y Hora (UTC) | Trascendencia técnica |
|---|---|---|
| 0 | 1970-01-01 00:00:00 UTC | La época Unix (Día cero del tiempo POSIX) |
| 1.000.000.000 | 2001-09-09 01:46:40 UTC | Hito del "Billenium" Unix (primer timestamp epoch de 10 dígitos) |
| 1.500.000.000 | 2017-07-14 02:40:00 UTC | 1.500 millones de segundos transcurridos desde el origen epoch |
| 2.000.000.000 | 2033-05-18 03:33:20 UTC | Hito de los 2.000 millones de segundos |
| 2.147.483.647 | 2038-01-19 03:14:07 UTC | Problema del año 2038 (Y2038): valor máximo para un entero de 32 bits con signo |
| 4.294.967.295 | 2106-02-07 06:28:15 UTC | Valor máximo para un entero de 32 bits sin signo |
Guía para desarrolladores: Implementación en diferentes lenguajes
Patrones de biblioteca estándar para obtener la marca de tiempo actual y convertir enteros Unix en fechas UTC.
// Segundos:
Math.floor(Date.now() / 1000);
// Milisegundos:
Date.now();const date = new Date(timestamp * 1000);
console.log(date.toISOString());
console.log(date.toUTCString());Casos de uso fundamentales en sistemas de producción
- Claims en tokens JWT (RFC 7519): Los campos de validación estándar como
exp(fecha de expiración),iat(emitido en) ynbf(no antes de) están tipificados estrictamente como enteros epoch en segundos. - Expiración de caché en memoria: Comandos de Redis como
EXPIREAT clave timestampy políticas de TTL en Memcached requieren marcas Unix absolutas para una invalidación predecible y sincronizada. - Cabeceras de limitación de tasa (Rate Limiting): Las APIs públicas devuelven la cabecera
X-RateLimit-Resetcomo un entero epoch para que las aplicaciones cliente calculen períodos de reintento con independencia del desfase de reloj local. - Trazabilidad distribuida (Spans): OpenTelemetry y Jaeger emplean marcas de tiempo en nanosegundos de 64 bits para calcular la duración exacta de ejecuciones entre microservicios y correlacionar gráficos de cascada.
Frequently Asked Questions
¿Cómo convertir una marca de tiempo Unix en una fecha y hora legible?
Pegue la marca de tiempo numérica en el campo de entrada. El conversor detecta de forma automática si el valor corresponde a segundos, milisegundos, microsegundos o nanosegundos, y presenta al instante la fecha calculada en tiempo universal coordinado (UTC), en la zona horaria local de su dispositivo, en estándar ISO 8601 (AAAA-MM-DDTHH:mm:ssZ) y en RFC 2822.
¿Cómo identificar si una marca de tiempo está expresada en segundos, milisegundos, microsegundos o nanosegundos?
El método más directo es contar el número de dígitos: 10 dígitos indican segundos (estándar en sistemas POSIX, Python, PHP y Go); 13 dígitos corresponden a milisegundos (JavaScript Date.now() y Java System.currentTimeMillis()); 16 dígitos representan microsegundos (Python time_ns() // 1000 y registros de bases de datos); y 19 dígitos representan nanosegundos (Go UnixNano y el subsistema de marcas de tiempo del kernel de Linux).
¿Por qué la fecha convertida muestra enero de 1970?
Esta anomalía se produce cuando se pasa un valor en segundos de 10 dígitos (por ejemplo, 1757419200) de forma directa a la función new Date(timestamp) en JavaScript. Dado que el motor de JavaScript espera milisegundos (13 dígitos), interpreta 1.750 millones de milisegundos como apenas unos 20 días transcurridos desde el 1 de enero de 1970. Para solucionarlo, multiplique el valor en segundos por 1.000 antes de procesarlo: new Date(timestamp * 1000).
¿Cómo convertir una fecha del calendario en una marca de tiempo Unix?
Seleccione la pestaña "Fecha → Timestamp", elija la fecha y la hora deseadas, defina la zona horaria de referencia (hora local del navegador, UTC o un desfase personalizado) y obtendrá inmediatamente la marca de tiempo Unix epoch sincronizada tanto en segundos como en milisegundos.
¿Afectan los husos horarios o el horario de verano (DST) al valor de la marca de tiempo Unix?
No. Las marcas de tiempo Unix se miden exclusivamente tomando como base UTC (Tiempo Universal Coordinado) desde el punto de origen de la época (1970-01-01 00:00:00 UTC). Una marca de tiempo Unix identifica el mismo instante absoluto en cualquier lugar del planeta. Las zonas horarias y el horario de verano son únicamente transformaciones visuales de formato aplicadas en la capa de presentación para el usuario final.
¿En qué consiste el problema del año 2038 (Y2038)?
El 19 de enero de 2038 a las 03:14:07 UTC, las marcas de tiempo almacenadas como enteros de 32 bits con signo alcanzarán su capacidad máxima positiva de 2.147.483.647. Al transcurrir el segundo siguiente, se produce un desbordamiento binario que convierte el valor en negativo (-2.147.483.648), interpretando erróneamente la fecha como el 13 de diciembre de 1901. Los sistemas modernos de 64 bits son inmunes a este fallo, ya que un entero de 64 bits puede representar fechas hasta más de 292.000 millones de años en el futuro.
¿Puede una marca de tiempo Unix tener un valor negativo?
Sí. Los números negativos representan instantes cronológicos anteriores al 1 de enero de 1970. Por ejemplo, -86400 corresponde al 31 de diciembre de 1969 a las 00:00:00 UTC, y -315619200 representa el 1 de enero de 1960. La herramienta admite plenamente marcas de tiempo negativas en todas las resoluciones numéricas.
¿Cuál es la diferencia entre los formatos UTC, ISO 8601 y RFC 2822?
UTC es la referencia horaria internacional sin desfases locales. ISO 8601 (2026-09-16T12:00:00Z) es la norma internacional preferida para interfaces de programación (APIs) e intercambio estructurado entre máquinas. RFC 2822 (Wed, 16 Sep 2026 12:00:00 +0000) es el estándar de formato de mensajes de correo electrónico (SMTP/MIME), mientras que las cabeceras HTTP (como Last-Modified y Date) emplean el formato derivado IMF-fixdate según RFC 7231 / RFC 1123.