Convertidor de Fechas ISO

Sobre el Convertidor de Fechas ISO 8601

Los formatos de fecha y hora son un cementerio de estándares incompatibles: ISO 8601 (formas básica y extendida), RFC 2822, RFC 3339, SQL DATETIME, Unix epoch en segundos / milisegundos / microsegundos / nanosegundos, seriales Excel, Día Juliano, fecha semana ISO, fecha ordinal ISO — y cada sistema maneja zonas horarias y segundos intercalares de forma distinta. Este convertidor acepta casi cualquier cosa (pégalo, la herramienta autodetecta) y produce todas las formas comunes simultáneamente, junto con cuatro zonas horarias seleccionables, día del año, semana ISO, trimestre, año bisiesto y un texto de tiempo relativo ('hace 3 horas', 'en 2 días').

Sin llamadas de red, sin cookies, sin logs — pura aritmética en el navegador contra la base IANA de tu máquina. Ideal para depurar logs, probar contratos de API, planificar entre equipos y exportar a hojas de cálculo.

¿Cuál es la diferencia real entre los formatos ISO 8601 'básico' y 'extendido'?

El formato extendido (el habitual) usa separadores: 2026-05-17T14:30:00.000Z. El básico los elimina: 20260517T143000Z. Contienen información idéntica; el básico se diseñó para sistemas con sets de caracteres limitados (mainframes, códigos de barras, nombres de archivo en Windows que prohíben dos puntos). El ecosistema moderno prefiere extendido para legibilidad, pero el básico aún aparece en logging industrial, timecode SMPTE de broadcast y firmware embebido. RFC 3339 (el perfil HTTP de ISO 8601) prohíbe explícitamente el básico y exige extendido con 'T' o ' ' como separador y 'Z' o '+HH:MM' como zona — por eso la mayoría de APIs REST aterrizan en 2026-05-17T14:30:00Z.

¿Cómo detecta la herramienta si mi número son segundos, milisegundos, microsegundos o nanosegundos?

Por orden de magnitud. Unix epoch en segundos es un número de 10-11 dígitos para cualquier fecha de nuestra vida (1e9 ≈ 2001, 5e9 ≈ 2128). Milisegundos añade 3 ceros (1e12 ≈ 2001 en ms). Microsegundos otros 3 (rango 1e15). Nanosegundos otros 3 (rango 1e18). El parser verifica: abs(n) < 1e11 → segundos; < 1e14 → ms; < 1e17 → µs; si no → ns. Es inequívoco para fechas entre ~1970 y 5000 d.C. Casos límite: un '0' literal se trata como segundos (1970-01-01 UTC). Un número de 13 dígitos siempre es milisegundos. Si tienes epoch real con precisión de segundo en 2086 o más allá (>11 dígitos), añade aclaración — pero no es problema 2026.

¿Por qué el tiempo relativo dice 'en 2 días' para una fecha que claramente está solo a 47 horas?

El tiempo relativo redondea a la unidad entera más cercana — 47 horas se redondea a 2 días porque la unidad mayor (días) está más cerca de un corte limpio. Lógica de corte: bajo 60 segundos → 'ahora mismo' o 'X segundos'; bajo 1 hora → 'X minutos'; bajo 1 día → 'X horas'; bajo 30 días → 'X días'; bajo 1 año → 'X meses'; si no 'X años'. Coincide con las convenciones de Intl.RelativeTimeFormat usadas por navegadores, notificaciones del SO y la mayoría de mensajería. Para aritmética de precisión exacta (ej. 'cuántos minutos hasta mi reunión de 15h'), usa la salida de epoch en segundos y resta.

¿Qué es una fecha semana ISO y cuándo usarla?

Las fechas semana ISO expresan una fecha como 'año-semana-día semana' (ej. 2026-W21-3 = miércoles de la semana 21 de 2026). Dos peculiaridades: (1) las semanas ISO empiezan en lunes (no domingo como en EE.UU.); (2) la semana 1 contiene el primer jueves del año — esto significa que 1-3 de enero pueden pertenecer a la semana 52 o 53 del año ISO anterior. Usa fechas semana ISO para: sistemas de nómina/hojas de horas (resúmenes semanales), planificación retail (52 semanas estables al año), planificación broadcast, sprints que tratan semanas como unidad atómica y gráficos UCI que muestran 'días desde admisión'. Evita para comunicación humana ('reserva la reunión para la semana 21' no significa nada sin calendario).

¿Las cuatro columnas de zona horaria están sincronizadas al mismo instante?

Sí — las cuatro columnas renderizan el mismo instante UTC (lo que parsee tu entrada), solo expresado en distintas zonas IANA. Si entras 2026-05-17T12:00:00Z, verás 12:00 en UTC, 05:00 en Los Ángeles (UTC-7 con DST), 08:00 en Nueva York (UTC-4 con DST) y 19:00 en Ho Chi Minh (UTC+7). El Intl.DateTimeFormat del navegador maneja transiciones DST, offsets de media hora y 45 minutos (India es UTC+5:30, Nepal UTC+5:45) y cambios históricos de reglas vía la tzdata IANA incluida. Útil para coordinar equipos entre continentes, correlacionar logs y verificar que tu backend escribe strings UTC con sufijo Z en vez de serializar la hora local.

¿Por qué el serial Excel no coincide con lo que muestra Excel en mi ordenador?

Excel usa dos sistemas de fechas y la mayoría no se entera. Default ('sistema 1900'): día 1 = 1900-01-01, con el bug famoso de tratar 1900 como bisiesto (no lo era) — añade un día 60 fantasma 1900-02-29 que nunca existió. Mac heredado ('sistema 1904'): día 1 = 1904-01-01. Este convertidor produce contra el sistema Windows 1900 (default para nuevos libros) pero compensa el bug bisiesto anclando en 1899-12-30, el truco que el propio Excel usa internamente para producir matemáticas correctas desde el 1900-03-01 en adelante. Si trabajas en libro Mac-1904, resta 1462 a nuestro serial. Para comprobar qué sistema usa tu libro: Archivo → Opciones → Avanzadas → 'Usar sistema de fechas 1904'.

¿Para qué sirve el Día Juliano y por qué es decimal?

El Día Juliano (JDN) es una cuenta continua de días desde mediodía UTC del 1 de enero de 4713 a.C. (la época Juliana proléptica elegida por astrónomos en 1583 porque precede todo registro histórico superviviente). La parte decimal es la fracción del día pasado el mediodía UTC: .0 = mediodía, .5 = medianoche. JDN domina en astronomía, mecánica orbital y aritmética de fechas históricas porque ignora reformas calendáricas (Juliano → Gregoriano en 1582, no adoptado por algunos países hasta el siglo XX). El JDN actual está cerca de 2.460.829. El Día Juliano Modificado (MJD) es JDN − 2.400.000,5, más corto y usado en telemetría espacial y estándares CCSDS. Si no estás en astronomía o aeroespacial, probablemente no lo necesites — pero los gurús de hojas de cálculo lo usan para restas limpias (días delta = JDN_b − JDN_a).

¿Cómo maneja la herramienta los segundos intercalares y las fechas anteriores a 1970?

Segundos intercalares: no los maneja. Tanto Unix epoch como el objeto Date de JavaScript ignoran explícitamente los segundos intercalares — cada día UTC es exactamente 86.400 segundos. El UTC real lleva 27 segundos intercalares añadidos desde 1972, así que técnicamente hay un offset de ~27 segundos entre el UTC mostrado y el tiempo atómico 'real'. Importa para: GPS, timestamps de mercados financieros (post-MiFID II), mediciones científicas de alta precisión. No importa para: logs, timestamps de API, planificación, todo lo humano. Para fechas antes de 1970, la herramienta las maneja — valores epoch negativos, fechas como 1066-10-14 (Batalla de Hastings) y a.C. funcionan vía Date, aunque la extensión gregoriana proléptica significa que la fecha mostrada puede no coincidir con el Juliano en vigor entonces. Para trabajo calendárico histórico-preciso, usa una librería de astronomía.