IANA timezone

Um IANA timezone é um identificador canônico como Europe/London, America/New_York, ou Asia/Tokyodo Banco de Dados de Fusos Horários da IANA (também chamado de “tzdata” ou “banco de dados Olson” em homenagem ao seu mantenedor original, Arthur David Olson).

Cada entrada captura todas as regras históricas e atuais para offset UTC e comportamento de horário de verão de uma região. “Europe/London” codifica: GMT (UTC+0) no inverno, BST (UTC+1) no verão, as datas precisas de transição de DST, e peculiaridades históricas anteriores a 1971. Inserir uma data e zona em qualquer linguagem de programação moderna retorna o offset correto porque o tzdata está integrado ao sistema operacional.

A convenção de nomenclatura é Região/Cidade, onde Região é uma de Africa, America,Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific, mais os especiais UTC, Etc/GMT, etc. Cidade é uma cidade canônica dentro da zona — Istanbul representa toda a Turquia, New_York representa o fuso horário Leste dos EUA, e assim por diante.

O conversor de fuso horário do Convertitive funciona com base no tzdata em nível de sistema operacional do navegador via Intl.DateTimeFormat, então transições de DST e mudanças de offset estão sempre atualizadas sem que o Convertitive precise enviar atualizações.

Exemplo prático

Você está agendando uma reunião semanal recorrente às “terças-feiras às 09:00 horário de Nova York” para participantes em NYC, Londres e Tóquio. Armazene a reunião como { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. O calendário do participante de Londres resolve cada ocorrência: em janeiro, NY está no EST (UTC−5) e Londres no GMT (UTC+0), então a reunião é às 14:00 em Londres. Em março (após o início do DST nos EUA mas antes do DST europeu), NY está no EDT (UTC−4) e Londres no GMT, então a reunião é às 13:00 em Londres — uma hora mais cedo. Em junho, ambos no horário de verão, NY EDT (UTC−4) e Londres BST (UTC+1), então a reunião é às 14:00 em Londres novamente. Tóquio (UTC+9, sem DST) vê a reunião variar entre 22:00 e 23:00 dependendo da temporada. Agora imagine que a equipe tivesse armazenado a reunião como “14:00 UTC” — o participante de NY experimentaria o horário da reunião variando com as mudanças de DST, e a convenção de “terça às 9h” quebraria silenciosamente duas vezes ao ano.

Quando e por que importa

IANA timezones importam no momento em que um sistema processa datas em mais de um usuário, mais de um local ou mais de uma estação. O erro a evitar no armazenamento é usar offsets fixos — “Asia/Karachi” sobrevive a uma futura reintrodução de DST; “UTC+5” não. O erro a evitar na exibição é renderizar timestamps sem especificar o fuso de destino — um log de backend mostrando “2026-05-22 14:30” sem tag de fuso é ambíguo e impossível de pesquisar. O erro a evitar na lógica de negócios é realizar aritmética de “adicionar 1 dia” em UTC em vez de no horário local durante transições de DST — “próximo dia mesmo horário de parede” pode ter 23 ou 25 horas de distância em UTC dependendo se o DST começa naquela noite. Bibliotecas modernas de data e hora (API Temporal do JavaScript, zoneinfo do Python, java.time do Java) lidam com isso corretamente quando recebem identificadores IANA; APIs mais antigas (Date nativo do JavaScript, moment.js sem plugin de timezone) produzem silenciosamente respostas erradas. Referência: RFC 6557 — Procedimentos para Manutenção do Banco de Dados de Fusos Horários.

O ciclo de lançamento do tzdata da IANA:os lançamentos do tzdata são versionados por ano + letra minúscula — 2024a, 2024b, 2025a, e assim por diante. Lançamentos acontecem sob demanda, geralmente 4-8 vezes por ano, sempre que um governo muda regras de DST ou o offset de fuso horário de uma região. Mudanças recentes notáveis: o México aboliu o DST em todo o país em 2022; a Rússia abandonou e depois restaurou o horário de inverno permanente em múltiplas revisões; o Líbano teve um início de DST atrasado por uma semana em 2023 devido a disputa política. Todos os sistemas operacionais recebem as mudanças por meio de atualizações de pacotes rotineiras — mas dispositivos IoT e telefones antigos que não atualizam automaticamente podem derivar, levando ao clássico problema de “meu relógio está uma hora adiantado” durante a primeira semana após uma mudança de regra de DST.

Por que nunca armazenar offsets diretamente:o erro mais comum no código de data e hora é armazenar “UTC+2” em vez de Europe/Istanbul. O offset captura um fato pontual sobre a zona, mas não as regras. Se a Turquia reintroduzir o DST (aboliu o DST em 2016, mas mudanças de regras são comuns na região), todos os registros com “UTC+2” ficam errados da noite para o dia. Armazene o identificador de zona IANA e deixe a consulta calcular o offset correto para cada timestamp. Relacionado: UTC, segundo intercalar. Referência: Banco de Dados de Fusos Horários da IANA.