O Que Realmente É o Banco de Dados de Fusos Horários da IANA
Se você já trabalhou com datas e horários em software, você dependeu do Banco de Dados de Fusos Horários da IANA, sabendo disso ou não. Ele é conhecido por vários nomes — banco de dados tz, tzdata, o banco de dados Olson ou zoneinfo — mas todos se referem à mesma coisa: um catálogo colaborativo e disponível gratuitamente dos fusos horários do mundo e das regras que os governam.
A palavra "catálogo" é modesta. O banco de dados não apenas lista quais regiões estão em qual offset UTC. Ele registra a história completa da medição civil do tempo para cada região — cada mudança de offset, cada transição de horário de verão, cada ajuste de relógio em tempos de guerra e cada regra futura programada — remontando, em muitos casos, a meados do século XIX, quando o horário médio local deu lugar a zonas padronizadas. Quando seu aplicativo de calendário mostra corretamente que uma reunião em 1985 aconteceu uma hora a mais ou a menos do mesmo horário de parede hoje, é o banco de dados tz em ação.
Ele é baseado em texto, legível por humanos e pequeno. A forma binária compilada que vem no seu computador tem apenas alguns megabytes. No entanto, ele codifica um dos conjuntos de dados mais silenciosamente complexos da computação.
Uma Breve História
O projeto começou na década de 1980 sob Arthur David Olson, que montou a primeira versão e a hospedou em servidores dos Institutos Nacionais de Saúde dos EUA. Por décadas, foi mantido principalmente por um esforço voluntário coordenado por uma lista de discussão pública, razão pela qual o nome mais antigo "banco de dados Olson" ainda aparece na documentação.
Paul Eggert assumiu como editor principal e continua sendo o coordenador de longa data do projeto. Sua compilação do documento theory.html que o acompanha e o meticuloso histórico de commits transformaram o banco de dados tanto em uma referência histórica quanto técnica.
Em 2011, após uma breve, mas alarmante, disputa legal sobre os dados históricos, a administração passou para a Internet Assigned Numbers Authority (IANA), o mesmo órgão que coordena outros recursos essenciais da internet. A IANA agora publica versões oficiais, razão pela qual "banco de dados de fusos horários da IANA" se tornou o nome canônico. O trabalho ainda é feito pela mesma comunidade de colaboradores; a IANA fornece um lar institucional e um ponto de distribuição estável.
A Convenção de Nomenclatura: Área/Localização
Uma das características mais distintivas do banco de dados é como ele nomeia os fusos. Em vez de nomes de países ou offsets brutos, ele usa um formato Área/Localização, quase sempre ancorado em uma cidade representativa:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
A "Área" geralmente é um continente ou oceano (America, Europe, Asia, Pacific), e a "Localização" é uma cidade conhecida dentro do fuso. Essa escolha parece peculiar até que você entenda a lógica por trás dela.
Cidades são estáveis; fronteiras políticas e offsets não são. Países se dividem, se unem, mudam de nome e alteram seus relógios. Uma cidade, por outro lado, é um ponto geográfico fixo com um histórico contínuo de medição do tempo. Nomear um fuso como America/New_York em vez de "Horário do Leste dos EUA" ou "UTC-5" significa que o identificador permanece válido mesmo à medida que as regras associadas a ele evoluem.
O banco de dados também evita deliberadamente nomes de países para contornar disputas políticas e porque um único país geralmente contém vários fusos — os Estados Unidos têm mais de uma dúzia. Ele escolhe a cidade mais populosa ou historicamente significativa em cada fuso distinto como um rótulo neutro. Quando duas regiões compartilham um histórico de relógio idêntico desde 1970, elas compartilham um fuso; no momento em que suas histórias divergem, elas recebem entradas separadas.
Por Que Offsets Brutos Não São Suficientes
Um instinto comum de iniciante é armazenar um horário como "UTC+5:30" e considerar resolvido. Isso funciona para um instante único, mas falha no momento em que você precisa raciocinar sobre eventos futuros ou recorrentes, porque os offsets não são propriedades estáticas de um lugar. Eles são o resultado de regras que os governos mudam constantemente e, muitas vezes, abruptamente.
Considere alguns exemplos reais que o banco de dados teve que absorver:
- Samoa pulou o dia 30 de dezembro de 2011 inteiramente. Para alinhar seu dia útil com a Austrália e a Nova Zelândia, em vez dos Estados Unidos, Samoa saltou a Linha Internacional de Data, mudando de UTC-11 para UTC+13. Para qualquer pessoa nas ilhas, aquela sexta-feira simplesmente não existiu.
- Países abolem, adotam ou reprogramam o horário de verão com pouco aviso. A União Europeia tem debatido o fim do horário de verão; vários países e estados dos EUA mudaram suas regras de horário de verão nas últimas décadas. Turquia, Rússia e outros mudaram seus offsets padrão completamente.
- As datas de início e fim do horário de verão mudam. Os Estados Unidos mudaram seus limites de horário de verão em 2007. Qualquer sistema que codificou a regra antiga produziu silenciosamente horários errados por semanas a cada ano.
Se você armazenar apenas um offset, não poderá responder à pergunta "qual será o horário local em Santiago em 15 de novembro do próximo ano?" — porque a resposta depende de regras que podem nem estar finalizadas ainda. Armazenar o identificador de fuso (America/Santiago) mais o banco de dados permite que o software calcule o offset correto para qualquer momento, passado ou futuro, e o recalcule automaticamente quando as regras mudarem.
Esta é a proposta de valor central: o banco de dados tz separa a identidade de um lugar das regras em constante mudança que determinam seu relógio.
Como Ele É Mantido
A manutenção acontece abertamente. As alterações propostas — uma nova regra de horário de verão, uma data histórica corrigida, um anúncio governamental — são discutidas na lista de discussão pública tz, onde os colaboradores citam diários oficiais, notícias e decretos governamentais como evidência. A precisão é levada a sério; mudanças em dados históricos, em particular, são examinadas em relação a fontes primárias.
As versões são numeradas com um ano e uma letra: 2024a, 2024b, 2024c e assim por diante. O número é o ano; a letra incrementa a cada versão naquele ano. Como os governos anunciam mudanças de horário em seus próprios cronogramas imprevisíveis, não há uma cadência fixa de lançamento — um ano tranquilo pode ter duas versões, enquanto um ano de turbulência política vê muitas. Espera-se que os sistemas atualizem prontamente, pois um banco de dados desatualizado pode significar exibir o horário errado após uma mudança de regra entrar em vigor.
Quem Depende Dele
Quase tudo.
- Sistemas operacionais. As distribuições Linux enviam
tzdatacomo um pacote principal. O macOS deriva seus dados de fuso da mesma fonte. O Windows usa seus próprios fusos baseados em registro por razões legadas, mas expõe fusos IANA por meio da biblioteca ICU e APIs modernas. - Linguagens de programação. Praticamente toda biblioteca madura de data/hora lê ou inclui o banco de dados tz:
zoneinfodo Python,java.timedo Java, o projeto ICU, PostgreSQL, mecanismos JavaScript via ICU, Ruby, PHP e muitos outros. - Aplicativos. Calendários, sistemas de reservas, plataformas de negociação financeira, ferramentas de análise de logs e serviços de agendamento dependem dele, geralmente sem que seus desenvolvedores pensem nisso.
Essa onipresença é exatamente a razão pela qual o banco de dados é tão importante. Uma única fonte de verdade, compartilhada e cuidadosamente mantida, significa que uma reunião agendada em um sistema é exibida corretamente em outro, em diferentes sistemas operacionais e linguagens, décadas no passado ou no futuro.
Se você quiser explorar os próprios fusos, navegue pela lista completa de fusos IANA ou veja como eles se mapeiam pelo mundo em nosso diretório de todos os fusos.
Perguntas Frequentes
O banco de dados tz é o mesmo que tzdata, zoneinfo e o banco de dados Olson?
Sim. Esses são todos nomes para o mesmo projeto. "tzdata" geralmente se refere aos arquivos de dados conforme empacotados para um sistema operacional, "zoneinfo" ao diretório binário compilado e "banco de dados Olson" é o nome histórico mais antigo, em homenagem ao fundador Arthur David Olson. Hoje, o nome oficial é Banco de Dados de Fusos Horários da IANA.
Com que frequência o banco de dados é atualizado?
Não há um cronograma fixo. As versões são desencadeadas por eventos do mundo real — um governo mudando suas regras de horário de verão ou offset padrão, ou uma correção em dados históricos. Alguns anos veem uma única versão; outros veem várias. Cada uma é nomeada como 2024a, 2024b, incrementando a letra ao longo do ano.
Por que ele nomeia fusos com nomes de cidades como America/New_York?
As cidades são geograficamente fixas e têm históricos contínuos de medição do tempo, enquanto países, fronteiras e offsets mudam ao longo do tempo. Usar uma cidade representativa dá a cada fuso um identificador estável e politicamente neutro que permanece válido mesmo quando as regras subjacentes de horário de verão ou offset mudam.
Posso simplesmente armazenar um offset UTC em vez de um nome de fuso?
Apenas para um único instante fixo. Para eventos futuros ou recorrentes, você deve armazenar o identificador do fuso, porque os offsets mudam com o horário de verão e decisões governamentais. O nome do fuso mais o banco de dados permite que o software calcule o offset correto para qualquer data automaticamente.
Quem administra o projeto agora?
Ele é publicado pela IANA, que assumiu a administração em 2011, e coordenado por Paul Eggert com uma comunidade de colaboradores que trabalham na lista de discussão pública tz. O trabalho técnico continua sendo um esforço colaborativo e voluntário.