Convertidor de timestamp

Un timestamp Unix cuenta segundos desde el epoch Unix 1970-01-01T00:00:00Z UTC, según POSIX.1-2017 (IEEE Std 1003.1-2017) definición de `time_t`. El `Date.now()` de JavaScript según ECMA-262 §21.4 devuelve milisegundos desde ese mismo epoch como un doble IEEE-754 (así valores en torno a 1,7×10¹² para fechas de 2026). Ida y vuelta: `new Date(timestamp_ms).toISOString()` → cadena ISO 8601-1:2019 como `"2026-05-10T22:00:00.000Z"`; `new Date(iso_string).getTime()` → vuelta a ms. La página detecta automáticamente si la entrada está en segundos (valores de 10 dígitos) o milisegundos (valores de 13 dígitos) por magnitud, ya que el mismo número significa puntos diferentes en el tiempo según la unidad (1700000000 segundos = 2023; 1700000000 ms = 1970).

El problema Y2038 es el desbordamiento del timestamp Unix: POSIX `time_t` como entero con signo de 32 bits se desborda en 2³¹ − 1 = 2.147.483.647 segundos, correspondientes a las 03:14:07 UTC del martes 19 de enero de 2038. Pasado eso, el contador desborda a negativo, rompiendo la aritmética de fechas y produciendo silenciosamente resultados equivocados para cualquier timestamp posterior. Migraciones modernas de SO a `time_t` de 64 bits: kernel Linux 5.6 (marzo de 2020); macOS 64 bits desde 10.7 Lion (2011); Windows NT internamente desde hace décadas. Sistemas vulnerables: controladores embebidos (industriales, automotrices, electrodomésticos), SCADA antiguos, binarios de 32 bits en SO de 64 bits, sistemas mainframe COBOL con campos de tiempo de 32 bits, formatos de fichero como ext2/ext3 (ext4 tiene 64 bits), algunas columnas TIMESTAMP de bases de datos. El rango de doble IEEE-754 de JavaScript ±100.000.000 días desde epoch cubre hasta el año 275760, así que los navegadores mismos son inmunes — pero los timestamps que pasan por un servidor de 32 bits y vuelven pueden corromperse.

Diferentes sistemas usan unidades de tiempo distintas en el mismo campo conceptual de "timestamp Unix", y mezclarlas produce silenciosamente fechas equivocadas. Segundos (tradición Unix, POSIX `time_t`, MySQL UNIX_TIMESTAMP(), time.Unix() de Go): enteros de 10 dígitos para fechas actuales (1,7×10⁹). Milisegundos (JavaScript Date.now(), Java System.currentTimeMillis(), iOS NSDate timeIntervalSince1970 × 1000): enteros de 13 dígitos (1,7×10¹²). Microsegundos (almacenamiento interno TIMESTAMP de PostgreSQL, datetime.timestamp() × 10⁶ de Python): enteros de 16 dígitos (1,7×10¹⁵). Nanosegundos (time.Now().UnixNano() de Go, clock_gettime CLOCK_REALTIME de Linux): enteros de 19 dígitos (1,7×10¹⁸). El conversor auto-detecta por número de dígitos: ≤10 dígitos → segundos; 11-13 → milisegundos; 14-16 → microsegundos. Un timestamp "1700000000" es el año 2023 si son segundos, pero 1970 si se interpreta como milisegundos — los errores silenciosos por factor 1000 son un fallo clásico al importar datos.

Tiempo Universal Coordinado (UTC) está actualmente 37 segundos por detrás del Tiempo Atómico Internacional (TAI): TAI − UTC = +37 s, en vigor desde el 1 de enero de 2017 tras el segundo intercalar más reciente (31 de diciembre de 2016 a las 23:59:60 UTC). Según IERS Bulletin C (publicado en enero + julio cada año), se han insertado 27 segundos intercalares desde la redefinición UTC de 1972 + 10 de offset inicial = 37 totales. El `time_t` de Unix NO cuenta segundos intercalares — hace como si cada día tuviera exactamente 86400 segundos, así que una inserción de segundo intercalar crea una ambigüedad de un segundo (el timestamp 1483228800 corresponde TANTO a 2016-12-31T23:59:60Z COMO a 2017-01-01T00:00:00Z en interpretación estricta). Las estrategias de smear gestionan esto sin romper la monotonicidad: Google lleva aplicando smear desde 2008 (inicialmente smear coseno de 20 horas, actualmente lineal de 24 horas de mediodía a mediodía); Meta/Facebook 17 horas; Amazon AWS Time Sync 24 horas alineado con Google. Nota: time.cloudflare.com aplica la corrección estándar del kernel en el instante UTC correspondiente — NO hace smear. El tiempo GPS funciona con TAI − 19 s y NO aplica smear; la secuenciación financiera de alta precisión y la astronomía necesitan herramientas que tengan en cuenta TAI.

ISO 8601-1:2019 es el estándar amplio de fecha-hora con muchos campos opcionales; RFC 3339 (Klyne y Newman, IETF Standards Track, julio de 2002) es el subconjunto estricto para protocolos de internet que requiere formato `YYYY-MM-DDTHH:MM:SS.ssssss±HH:MM` con offset de zona horaria obligatorio (no se admiten valores de fecha-hora sin offset). Un datetime sin zona horaria ("naive", sin info de offset, p. ej. `datetime(2026, 5, 10, 22, 0)` de Python) es ambiguo — la misma cadena significa momentos absolutos diferentes en Tokio vs Nueva York. Un datetime con zona horaria ("timezone-aware") (`datetime(2026, 5, 10, 22, 0, tzinfo=ZoneInfo("Europe/Madrid"))`) es inequívoco. Mapeo a bases de datos: TIMESTAMP WITHOUT TIME ZONE de PostgreSQL almacena reloj de pared; TIMESTAMP WITH TIME ZONE (timestamptz) almacena UTC + convierte al recuperar según zona horaria de sesión. La columna TIMESTAMP de MySQL convierte automáticamente hacia/desde UTC; DATETIME no. Buena práctica de almacenamiento: UTC + offset (RFC 3339); para visualización: convertir a zona horaria del usuario vía lookup en la base de datos IANA tz (ver herramienta hermana timezone-converter).