Convierte una fecha y hora entre dos zonas horarias IANA cualesquiera, con horario de verano incluido.
Utiliza los datos tzdata IANA de su navegador — las transiciones DST se manejan correctamente. Para uso aeronáutico/médico, confirme siempre con la fuente oficial.
Programar una reunión entre zonas horarias es la fricción diaria del trabajo remoto. "Martes a las 16:00 París" es inequívoco para un parisino y ambiguo para todos los demás: ¿son las 7:00 de la mañana en la hora estándar del Pacífico o en la hora de verano del Pacífico, dependiendo de si es primavera u otoño? El horario de verano difiere entre hemisferios (Sídney retrocede cuando París avanza) y entre décadas (en 2024 la mayor parte de Sudamérica abandonó el horario de verano por completo). El proyecto IANA tzdata mantiene el mapeo canónico de cada zona horaria nombrada a su historial de desfase, y todos los navegadores modernos envían una copia local que maneja las reglas automáticamente. Esta calculadora es el envoltorio de cara al usuario para esos datos: introduzca una fecha, una hora de reloj de pared y una zona horaria de origen; elija una zona horaria de destino; obtenga la hora de reloj de pared local equivalente en el destino, más el desfase entre las dos zonas para ese instante específico. Las 20 ciudades del desplegable cubren la mayoría de las reuniones interzonales: las principales capitales europeas, las zonas continentales de EE. UU., los cuatro centros de negocios asiáticos principales, las ciudades de negocios del hemisferio sur y la UTC como referencia inequívoca.
No hay una fórmula cerrada — la calculadora delega en la API Intl.DateTimeFormat del navegador, que tiene acceso a IANA tzdata a través del sistema operativo. Internamente: (1) Construir un instante UTC que, al interpretarse en la zona horaria de origen, muestre la hora de pared especificada por el usuario. Esto requiere un pequeño bucle de dos pasos: tomar las entradas como si fueran UTC, preguntar a Intl qué muestra la zona de origen para ese instante, calcular el desfase entre la hora de pared mostrada y la deseada, restar ese desfase para encontrar el instante UTC real. (2) Formatear el mismo instante UTC en la zona de destino utilizando Intl.DateTimeFormat con timeZone: <destino>. (3) Calcular la diferencia de desfase entre las dos zonas para ese instante específico — necesario porque el desfase no es fijo; varía con el horario de verano. El resultado incluye el día de la semana, la fecha completa, la hora y el minuto, y la abreviatura de la zona (CET, EST, JST, etc.) para mayor claridad.
Cuatro entradas: fecha (selector de fecha), hora (selector de hora de 24 horas), zona horaria de origen (desplegable), zona horaria de destino (desplegable). Valores predeterminados: hoy a las 14:30, París a Nueva York. El panel de resultados muestra la hora de origen y la hora de destino como dos grandes KPIs paralelos, y debajo de ellos la hora de referencia UTC y el desfase entre las dos zonas para ese instante. El desplegable de 20 ciudades cubre Europa (París, Londres, Berlín, Moscú), América (Nueva York, Chicago, Denver, Los Ángeles, São Paulo), África (El Cairo, Johannesburgo), Asia (Dubái, Bombay, Pekín, Tokio, Singapur, Seúl), Oceanía (Sídney, Auckland), más UTC. Agregue nuevas ciudades editando el desplegable; la maquinaria subyacente maneja cualquier identificador de zona IANA.
Un equipo de París quiere programar una reunión de inicio con su homólogo de Nueva York para el 15 de mayo de 2026 a las 14:30 hora de París. Origen: 14:30 del 15 de mayo de 2026 en Europe/Paris (CEST, UTC+2 en mayo porque el horario de verano está en vigor). Destino: America/New_York (EDT, UTC-4 en mayo). Origen a UTC: 14:30 - 02:00 = 12:30 UTC. UTC a destino: 12:30 + (-04:00) = 08:30 EDT. Por lo tanto, las 14:30 de París = 08:30 de Nueva York el mismo día, un desfase de 6 horas. Ahora considere el 15 de enero de 2026 a las 14:30 de París (CET, UTC+1) → Nueva York (EST, UTC-5). Origen a UTC: 14:30 - 01:00 = 13:30 UTC. UTC a destino: 13:30 - 05:00 = 08:30 EST. Misma conversión de hora de reloj, pero solo porque tanto París como Nueva York están en horario estándar; si París hubiera cambiado al horario de verano y Nueva York no (una situación real a finales de marzo cada año), el desfase sería de 5 horas en lugar de 6. La calculadora maneja esto de forma transparente: el usuario no necesita seguir el horario de verano entre dos zonas; la base de datos IANA lo hace por ellos. Un ejemplo más drástico: 15 de diciembre de 2026 a las 09:00 Sídney (AEDT, UTC+11) → Londres (GMT, UTC+0). Origen a UTC: 09:00 - 11:00 = -02:00 UTC, que son las 22:00 del día anterior. Londres a las 22:00 del 14 de diciembre — cruzando la línea de fecha en términos de calendario, 11 horas de diferencia en términos de reloj.
Primero, confundir el desfase UTC con la zona horaria. "UTC+1" describe el desfase; "Europe/Paris" describe la zona horaria. París es UTC+1 en invierno y UTC+2 en verano. Codificar manualmente UTC+1 para "hora francesa" produce un error de una hora desde finales de marzo hasta finales de octubre. Segundo, ignorar el horario de verano. París y Nueva York observan el horario de verano pero en diferentes horarios: a mediados de marzo, París todavía está en CET (UTC+1) durante dos semanas, mientras que Nueva York ya ha cambiado a EDT (UTC-4); el desfase es de 5 horas en lugar de 6 durante esa ventana. La calculadora maneja esto; las conversiones manuales suelen equivocarse. Tercero, mezclar notación de 12 y 24 horas entre culturas. EE. UU. y el Reino Unido usan coloquialmente relojes de 12 horas AM/PM; Europa continental utiliza 24 horas. El selector de la calculadora es de 24 horas; la salida de destino también utiliza 24 horas para evitar ambigüedades. Cuarto, programar cruces de línea de fecha sin darse cuenta. Tokio a las 09:00 del martes es San Francisco a las 17:00 del lunes — un desfase de 16 horas que cruza el día del calendario. La calculadora muestra la fecha completa en el destino, no solo la hora, para hacer esto visible. Quinto, tratar el conversor como autoritativo para uso legal o aeronáutico. La calculadora utiliza los datos tzdata del navegador, que se actualizan cuando se actualiza el sistema operativo; si el usuario está en un sistema antiguo, las reglas pueden estar desactualizadas para cambios recientes del horario de verano (por ejemplo, la abolición del horario de verano de Brasil en 2019, la eliminación parcial del horario de verano de México en 2022). Para contextos vinculantes, siempre verifique la fuente oficial.
Las zonas horarias son un sistema políticamente fluido. Los cambios del horario de verano son comunes: la UE ha estado debatiendo el fin del horario de verano desde 2018 (sin consenso alcanzado en 2025); Rusia abolió el horario de verano en 2014; México lo abolió en la mayoría de las regiones en 2022; Irán lo abolió en 2022. El proyecto IANA tzdata rastrea todos estos cambios y envía actualizaciones varias veces al año; los sistemas operativos modernos las obtienen automáticamente. Existen desfases de media hora y cuarto de hora: India es UTC+5:30, Irán UTC+3:30, Terranova UTC-3:30, Nepal UTC+5:45, Islas Chatham UTC+12:45. La calculadora maneja esto de forma transparente porque IANA lo hace. Las regiones polares utilizan la zona que sea administrativamente conveniente; las estaciones antárticas pueden seguir la hora de su nación de suministro. Las conversiones históricas (la hora de una reunión de 1956 en Berlín a Nueva York) también son compatibles con IANA, que registra el historial completo de desfases para cada zona. Las conversiones programáticas en código siempre deben almacenar las marcas de tiempo en UTC y convertir a hora local solo al mostrar; esta calculadora demuestra la conversión en el límite, donde el usuario ve el resultado.