Convertidor de Zonas Horarias

Las zonas horarias no son simplemente desplazamientos desde UTC — son regiones políticas y geográficas complejas con sus propias reglas. Hay 38 horas locales en uso en todo el mundo, con desplazamientos que van desde UTC-12:00 hasta UTC+14:00. Algunas zonas horarias usan desplazamientos de 30 minutos o 45 minutos (India es UTC+5:30, Nepal es UTC+5:45). El horario de verano (DST) añade otra capa de complejidad: no todos los países observan el DST, los que lo hacen empiezan y terminan en fechas diferentes, y las fechas cambian de un año a otro.

Historical timezone changes make things even harder. Countries frequently change their timezone rules -- Russia abolished DST in 2014, North Korea created its own timezone (UTC+8:30, later reverted to UTC+9) in 2015, and Chile has changed its DST rules multiple times. The IANA Time Zone Database (tzdata) tracks all these changes and is updated several times per year. Your browser uses this database via the Intl API, ensuring that historical timezone conversions are accurate. This is why you should never hard-code timezone offsets -- always use the IANA timezone name (e.g., 'America/New_York', not 'UTC-5').

A common mistake is confusing timezone offset with timezone. 'UTC-5' is an offset that changes twice a year for New York (UTC-5 during EST, UTC-4 during EDT). 'America/New_York' is a timezone that encapsulates the rules for when to switch. The Intl.DateTimeFormat API in modern browsers handles this correctly -- you specify the IANA timezone name and the API applies the correct offset for any given date and time.

Always store and transmit times in UTC. Convert to local time only for display. This eliminates ambiguity -- a UTC timestamp means the same thing everywhere in the world. When displaying times to users, use the Intl.DateTimeFormat API with the user's timezone (obtained from Intl.DateTimeFormat().resolvedOptions().timeZone) to show times in their local timezone automatically. For event scheduling, always include the timezone in the display (e.g., '3:00 PM EST' or '3:00 PM UTC-5') and consider using ISO 8601 format with timezone offset (e.g., 2024-01-15T15:00:00-05:00) for machine-readable data.

When scheduling meetings across timezones, use a tool that shows all participants' local times side by side. Be mindful of DST transitions -- a recurring meeting at '9 AM EST' doesn't exist during the DST gap in March. Also, some dates don't exist in all timezones: when the US springs forward, 2:00 AM to 3:00 AM doesn't exist, and when it falls back, 1:00 AM to 2:00 AM happens twice. These edge cases are handled automatically by the Intl API but can cause bugs if you're doing manual offset arithmetic.