Conversor de Zona Horaria

La base de datos IANA Time Zone (también llamada "tz database", "Olson database" por Arthur David Olson que la fundó en 1986, o "zoneinfo") es la fuente canónica de offsets UTC históricos y reglas DST para cada región — actualmente ~600 definiciones de zona cubriendo cada cambio de offset UTC, transición DST y decisión política de zona horaria desde 1970. Versión actual: 2026a (marzo de 2026), mantenida por Paul Eggert (UCLA) con múltiples actualizaciones por año conforme los gobiernos cambian las reglas. Por qué usar IDs de zona canónicos (Europe/Madrid, America/New_York, Asia/Tokyo) en vez de abreviaturas de zona horaria: las abreviaturas son ambiguas (CET puede significar Central European Time UTC+1 o, en algún código antiguo, Central Equatorial Time UTC+0; CST significa US Central, China Standard o Cuba Standard según el contexto). El ID de zona codifica el historial íntegro (Madrid fue UTC+0 hasta 1942, brevemente UTC+2 durante la 2ª Guerra Mundial, UTC+1 desde entonces con DST desde 1974) — un único ID resuelve correctamente cualquier fecha histórica o futura.

UE: según la Directiva 2000/84/CE de 19 de enero de 2001, adelanto del reloj último domingo de marzo a las 01:00 UTC (= 02:00 → 03:00 CET); atraso del reloj último domingo de octubre a las 01:00 UTC (= 03:00 → 02:00 CET). El Parlamento UE votó abolir el DST en marzo de 2019 pero la decisión final del Consejo sigue pendiente; los Estados miembros elegirían individualmente entre hora permanente de invierno (UTC+1) y verano (UTC+2). Estados Unidos: según la Energy Policy Act 2005 (extendida desde 2007), adelanto del reloj segundo domingo de marzo a las 02:00 local; atraso del reloj primer domingo de noviembre a las 02:00 local. Arizona (excepto Nación Navajo), Hawái, Puerto Rico, Guam, Islas Vírgenes de EE.UU., Samoa Americana, Islas Marianas del Norte no observan DST. Australia: estado por estado — NSW, Victoria, SA, Tasmania, ACT observan DST (octubre-abril, hemisferio opuesto); Queensland, NT, WA no. Brasil: abolió permanentemente el DST en 2019 (Decreto 9.772 de 25 de abril de 2019, administración Bolsonaro). Rusia: abolió DST en 2011, reintrodujo reglas diferentes en 2014. Türkiye: UTC+3 permanente desde el 7 de septiembre de 2016 (decreto del Resmi Gazete). Marruecos: WET+1 permanente (= UTC+1) desde el 26 de octubre de 2018 (Decreto 2-18-855). Japón, China, India: sin DST.

Cuando el adelanto del reloj por DST se dispara, los relojes saltan de 02:00 directamente a 03:00 — la ventana de 02:00:00 a 02:59:59 NO existe en hora local en esa fecha. Inversamente, fall-back hace que 02:00-02:59 ocurra dos veces (una antes de que los relojes retrocedan, una después). Trampas de programación: una reunión recurrente programada a las 02:30 local en UE el domingo del adelanto del reloj no tiene hora local válida — cada biblioteca lo gestiona de forma distinta (Python `pytz` lanza NonExistentTimeError, JavaScript desplaza hacia delante sin avisar, Java ZonedDateTime ofrece estrategias). Para el atraso del reloj, un timestamp registrado como "02:30 local" es ambiguo: no se sabe a cuál de las dos ocurrencias se refiere. RFC 3339 con offset explícito (`02:30-04:00` vs `02:30-05:00` para atraso del reloj US Eastern) desambigua; almacenar en UTC elimina el problema por completo. Las herramientas que manejan eventos recurrentes visibles al usuario deberían omitir explícitamente las horas inexistentes o elegir una estrategia documentada.

Notación de offset de zona horaria ISO 8601-1:2019: `Z` = UTC (offset cero, a menudo usado en logs y APIs); `±HH:MM` = offset explícito respecto a UTC. Ejemplos trabajados: `+00:00` = UTC (igual que Z); `+01:00` = Madrid invierno, Berlín invierno, Casablanca todo el año; `+02:00` = Madrid verano, Berlín verano, Atenas invierno, Estambul (permanente post-2016); `+03:00` = Moscú, Riyad, Estambul (permanente); `+05:30` = Hora estándar de India + Sri Lanka; `+03:30` = Irán (DST +04:30 abolido en septiembre de 2022); `+06:30` = Myanmar + Islas Cocos; `+09:30` = Adelaida estándar; `-03:30` = Terranova; `-09:30` = Islas Marquesas (otros offsets de media hora); `+05:45` = Nepal; `+12:45/+13:45` = Islas Chatham NZ (los únicos dos offsets de 45 minutos en uso actualmente); `+09:00` = Tokio, Seúl; `-05:00` = US Eastern invierno; `-08:00` = US Pacífico invierno. RFC 3339 requiere un offset explícito (no se admiten valores de fecha-hora sin offset). Los offsets UTC cambian históricamente — Rusia movió Moscú de UTC+3 a UTC+4 en 2011, de vuelta a UTC+3 en 2014.

Se elige una zona horaria de referencia (a menudo UTC o la de un participante en su casa) y se indica explícitamente tanto la hora local como el offset. Ejemplo: "9:00 EST (UTC-5) martes" = 14:00 UTC = 15:00 CET (invierno) / 16:00 CEST (verano) = 19:30 IST (UTC+5:30) = 23:00 JST (UTC+9). Trampas comunes: los cambios DST desplazan el offset durante medio año (US Eastern es UTC-5 invierno / UTC-4 verano); Madrid es UTC+1 invierno / UTC+2 verano; Sídney está en hemisferio opuesto así que UTC+10 invierno / UTC+11 verano (su invierno = nuestro verano). La base de datos IANA tz resuelve esto correctamente cuando se le da un ID de zona (America/New_York, Europe/Madrid, Australia/Sydney) — la base de datos tz contiene las reglas políticas y de DST, por lo que el mismo ID de zona produce offsets distintos para fechas distintas. Para invitaciones de calendario, conviene almacenar UTC + offset (RFC 3339) y convertir por destinatario; los ficheros ICS de calendario incluyen el ID de zona en el componente VTIMEZONE, que referencia los nombres IANA.