Por que ‘America/New_York’ é melhor do que ‘GMT-5’?

Porque America/New_York é uma regra, não um valor. Ela codifica EST, EDT e as datas de transição entre eles — atualmente o segundo domingo de março e o primeiro domingo de novembro. ‘GMT-5’ só está correto pela metade do ano. Qualquer sistema que use offsets fixos quebra silenciosamente toda primavera e outono.

Por que os relógios dos EUA e da UE não mudam no mesmo final de semana?

Os EUA mudam para o horário de verão no segundo domingo de março; a UE muda no último domingo de março. Há normalmente uma janela de uma a três semanas em que o offset EUA/UE é uma hora menor que o usual. Uma reunião das 9h em Nova York normalmente cai às 15h em Paris, mas cai às 14h durante essa janela. Convites recorrentes no calendário não levam isso em conta, a menos que tenham sido criados em um sistema com reconhecimento de fuso horário.

Qual é a melhor janela de sobreposição para Leste dos EUA e Europa Ocidental?

13:00–17:00 UTC funciona o ano todo. Isso equivale a aproximadamente 9h–13h em Nova York e 14h–18h em Londres (15h–19h CET). Evite a primeira hora após o fim do dia útil europeu — o engajamento cai acentuadamente.

Existe alguma sobreposição que inclua Oeste dos EUA e Ásia?

Mal. O horário do Pacífico e Tóquio se sobrepõem por aproximadamente uma hora na manhã do Pacífico / fim da noite em Tóquio (7h PT = 23h JST no inverno, meia-noite no verão). A maioria das equipes distribuídas globalmente aceita que esse par é assíncrono ou rotaciona o inconveniente.

Por que o Outlook e o Google Calendar discordam no mesmo convite?

Arquivos ICS podem codificar uma reunião com um instante UTC fixo mais uma zona de exibição, ou com um horário local ‘flutuante’. O Outlook historicamente usava uma abordagem, o Google a outra. Quando os clientes do remetente e do destinatário interpretam o campo de forma diferente, a reunião se desloca pelo offset de fuso horário. Sempre use um cliente com reconhecimento de fuso horário e verifique se o ICS contém um TZID.

Devo usar UTC para todo o agendamento interno?

Sim para armazenamento, não para exibição. Armazene cada evento como um instante UTC mais a zona IANA do criador. Exiba no fuso horário local de cada visualizador. Nunca agende uma reunião recorrente em ‘UTC’ como zona de exibição — ela não muda para o horário de verão, então a reunião vai derivar uma hora duas vezes por ano para a maioria dos participantes.

Guide

Agendamento entre fusos horários: um guia prático para equipes remotas

A reunião recorrente no seu calendário está errada duas vezes por ano, de duas formas diferentes, e ninguém te avisou.

By Buğra SözeriPublished May 31, 2026

Equipes distribuídas perdem uma quantidade absurda de tempo pelos mesmos poucos bugs de fuso horário: reuniões que mudam uma hora duas vezes por ano, convites de calendário que chegam no horário errado, “9h para todos” que não é. As correções são pequenas. O custo de não fazê-las é, em média, um lançamento de produto perdido por ano.

Use zonas IANA, não offsets fixos

O banco de dados de fusos horários IANA (frequentemente chamado de tzdata ou zoneinfo) é a fonte canônica para como os relógios se comportam ao redor do mundo. Cada zona — Europe/Istanbul, America/Los_Angeles, Asia/Tokyo — é uma regra: o histórico completo de offsets UTC, transições de horário de verão e mudanças políticas para aquela localização.

Um offset simples como GMT+3 ou UTC-5 é um valor. Ele acontece de estar correto para alguns lugares em algumas épocas do ano, mas não conhece o horário de verão nem qualquer mudança legal futura. A Turquia abandonou o horário de verão em 2016 e passou permanentemente para UTC+3; o Reino Unido fica em UTC+0 no inverno e UTC+1 no verão. Um sistema usando offsets fixos erra isso silenciosamente.

Regra geral: cada data-hora armazenada em seu banco de dados deve carregar um ID de zona IANA junto ao instante UTC. A zona diz como exibir; o instante diz quando realmente aconteceu. Nossa entrada de glossário de fuso horário IANA cobre o formato com mais profundidade.

Semanas de transição do horário de verão

A maneira mais confiável de encontrar bugs de fuso horário em um aplicativo de calendário é olhar para a segunda semana de março.

Estados Unidos mudam para o horário de verão no segundo domingo de março e voltam no primeiro domingo de novembro (desde 2007).
União Europeia muda no último domingo de março e volta no último domingo de outubro.
Reino Unido segue o calendário da UE (BST começa no último domingo de março).
Austrália (estados orientais) muda na direção oposta em outubro e abril — ficam no Hemisfério Sul.
Japão, China, Índia, a maior parte da África, a maior parte da América do Sul — sem horário de verão.

Consequências práticas: entre o segundo domingo de março e o último domingo de março, os EUA estão no horário de verão enquanto a Europa ainda está no horário padrão. A diferença usual de Nova York / Londres de 5 horas cai para 4. Uma reunião das 9h em Nova York que normalmente cai às 14h em Londres cai às 13h. Reuniões recorrentes armazenadas como “9h America/New_York” em um cliente com reconhecimento de fuso horário tratam isso corretamente. Reuniões armazenadas como “14:00 UTC” não tratam.

Janelas de sobreposição práticas

Leste dos EUA ↔ Europa Ocidental

13:00–17:00 UTC. Aproximadamente 9h–13h Eastern e 14h–18h Londres / 15h–19h Central Europeu. Ambos os lados estão claramente dentro do dia útil.

Oeste dos EUA ↔ Europa Ocidental

16:00–17:00 UTC. Uma janela de uma hora: 9h Pacífico = 17h Londres. Qualquer coisa mais cedo perde os europeus; qualquer coisa mais tarde perde o Pacífico.

Europa Ocidental ↔ Ásia (Tóquio, Cingapura, Seul)

08:00–10:00 UTC. 9h Londres = 18h Tóquio. Cedo para Londres, fim do dia para Tóquio.

Oeste dos EUA ↔ Ásia

14:00–15:00 UTC. 7h Pacífico = 23h Tóquio (inverno). Doloroso para ambos os lados.

Para consulta interativa, nosso planejador de reuniões mostra faixas de sobreposição em múltiplos fusos. O relógio mundial é bom para verificações rápidas de “é de madrugada para eles agora?”.

Armadilhas de convites de calendário

ICS sem TZID

O formato iCalendar (ICS) pode codificar uma reunião como um instante UTC (ex.: DTSTART:20260601T130000Z) ou como um horário local vinculado a uma zona (ex.: DTSTART;TZID=America/New_York:20260601T090000). A primeira forma é inequívoca quanto ao instante, mas não muda com o horário de verão. A segunda forma muda, porque o cliente do destinatário consulta a regra atual para a zona nomeada.

Reuniões recorrentes sempre devem usar a forma TZID.

Recomendações práticas

Armazene UTC + zona IANA. Duas colunas: uma para o instante absoluto, uma para a zona do criador. Exiba no fuso horário do visualizador.
Escolha horários de reuniões recorrentes pela faixa UTC, não pelo horário local.Um “13:00 UTC” semanal permanece na mesma janela de sobreposição durante todo o ano, mesmo que mude no relógio local por uma hora.
Audite reuniões recorrentes em torno das transições de horário de verão. Reserve 30 minutos na semana antes de cada transição para confirmar que os convites ainda chegam onde pretendido.
Padrão assíncrono. A correção de fuso horário mais barata é ter menos reuniões com presença obrigatória.
Use nomes de zona IANA nas ferramentas. “PST” é ambíguo. America/Los_Angelesnão é.

Experimente o planejador

Insira os fusos horários da sua equipe em nosso planejador de reuniões para ver faixas de sobreposição verde/vermelho ao longo de um dia de 24 horas. Para conversões pontuais, o conversor de fuso horário lida com entradas arbitrárias de data e hora.

Conclusão

Bugs de fuso horário são totalmente evitáveis. Use nomes de zona IANA, armazene UTC mais zona, agende reuniões recorrentes por faixa UTC e verifique em torno das semanas de transição do horário de verão. A maioria das frustrações relacionadas a calendários em equipes distribuídas remonta a uma dessas quatro regras sendo violada.

Frequently asked questions

Por que ‘America/New_York’ é melhor do que ‘GMT-5’?: Porque America/New_York é uma regra, não um valor. Ela codifica EST, EDT e as datas de transição entre eles — atualmente o segundo domingo de março e o primeiro domingo de novembro. ‘GMT-5’ só está correto pela metade do ano. Qualquer sistema que use offsets fixos quebra silenciosamente toda primavera e outono.
Por que os relógios dos EUA e da UE não mudam no mesmo final de semana?: Os EUA mudam para o horário de verão no segundo domingo de março; a UE muda no último domingo de março. Há normalmente uma janela de uma a três semanas em que o offset EUA/UE é uma hora menor que o usual. Uma reunião das 9h em Nova York normalmente cai às 15h em Paris, mas cai às 14h durante essa janela. Convites recorrentes no calendário não levam isso em conta, a menos que tenham sido criados em um sistema com reconhecimento de fuso horário.
Qual é a melhor janela de sobreposição para Leste dos EUA e Europa Ocidental?: 13:00–17:00 UTC funciona o ano todo. Isso equivale a aproximadamente 9h–13h em Nova York e 14h–18h em Londres (15h–19h CET). Evite a primeira hora após o fim do dia útil europeu — o engajamento cai acentuadamente.
Existe alguma sobreposição que inclua Oeste dos EUA e Ásia?: Mal. O horário do Pacífico e Tóquio se sobrepõem por aproximadamente uma hora na manhã do Pacífico / fim da noite em Tóquio (7h PT = 23h JST no inverno, meia-noite no verão). A maioria das equipes distribuídas globalmente aceita que esse par é assíncrono ou rotaciona o inconveniente.
Por que o Outlook e o Google Calendar discordam no mesmo convite?: Arquivos ICS podem codificar uma reunião com um instante UTC fixo mais uma zona de exibição, ou com um horário local ‘flutuante’. O Outlook historicamente usava uma abordagem, o Google a outra. Quando os clientes do remetente e do destinatário interpretam o campo de forma diferente, a reunião se desloca pelo offset de fuso horário. Sempre use um cliente com reconhecimento de fuso horário e verifique se o ICS contém um TZID.
Devo usar UTC para todo o agendamento interno?: Sim para armazenamento, não para exibição. Armazene cada evento como um instante UTC mais a zona IANA do criador. Exiba no fuso horário local de cada visualizador. Nunca agende uma reunião recorrente em ‘UTC’ como zona de exibição — ela não muda para o horário de verão, então a reunião vai derivar uma hora duas vezes por ano para a maioria dos participantes.

Published May 31, 2026