Converta uma data e hora entre quaisquer dois fusos horários IANA com horário de verão tratado.
Usa os dados tzdata IANA do seu navegador — transições de horário de verão são tratadas corretamente. Para uso aeronáutico/médico, sempre confirme com a fonte oficial.
Agendar uma reunião entre fusos horários é o atrito diário do trabalho remoto. "Terça-feira às 16h em Paris" é inequívoco para um parisiense e ambíguo para todos os outros: são 7h no horário de verão do Pacífico ou 7h no horário padrão do Pacífico, dependendo se é primavera ou outono? O horário de verão diverge entre os hemisférios (Sydney recua quando Paris avança) e entre décadas (em 2024 a maior parte da América do Sul abandonou o horário de verão completamente). O projeto IANA tzdata mantém o mapeamento canônico de cada fuso horário nomeado para seu histórico de desfasamento, e todos os navegadores modernos enviam uma cópia local que lida com as regras automaticamente. Esta calculadora é o invólucro voltado para o usuário em torno desses dados: insira uma data, uma hora de relógio e um fuso horário de origem; escolha um fuso horário de destino; obtenha a hora local equivalente no destino, mais o desfasamento entre as duas zonas para aquele instante específico. As 20 cidades no menu suspenso cobrem a maioria das reuniões entre fusos horários: as principais capitais europeias, as zonas continentais dos EUA, os quatro principais centros de negócios asiáticos, as cidades de negócios do hemisfério sul e a UTC como referência inequívoca.
Não existe uma fórmula de forma fechada — a calculadora delega para a API Intl.DateTimeFormat do navegador, que tem acesso ao tzdata da IANA através do sistema operacional. Internamente: (1) Construa um instante UTC que, quando interpretado no fuso horário de origem, exiba o relógio de parede especificado pelo usuário. Isto requer um pequeno loop de duas passagens: pegue as entradas como se fossem UTC, pergunte ao Intl o que a zona de origem mostra para esse instante, compute o desfasamento entre o relógio de parede exibido e o pretendido, subtraia esse desfasamento para encontrar o instante UTC real. (2) Formate o mesmo instante UTC na zona de destino usando Intl.DateTimeFormat com timeZone: <destino>. (3) Compute a diferença de desfasamento entre as duas zonas para esse instante específico — necessário porque o desfasamento não é fixo; ele varia com o horário de verão. O resultado inclui dia da semana, data completa, hora e minuto, e a abreviação da zona (CET, EST, JST, etc.) para clareza.
Quatro entradas: data (seletor de data), hora (seletor de hora no formato 24 horas), fuso horário de origem (menu suspenso), fuso horário de destino (menu suspenso). Padrões: hoje às 14:30, Paris para Nova Iorque. O painel de resultados mostra a hora de origem e a hora de destino como dois grandes KPIs paralelos, e abaixo deles a hora de referência UTC e o desfasamento entre as duas zonas para aquele instante. O menu suspenso de 20 cidades cobre a Europa (Paris, Londres, Berlim, Moscou), Américas (Nova Iorque, Chicago, Denver, Los Angeles, São Paulo), África (Cairo, Joanesburgo), Ásia (Dubai, Mumbai, Pequim, Tóquio, Singapura, Seul), Oceania (Sydney, Auckland), mais UTC. Adicione novas cidades editando o menu suspenso; a maquinaria subjacente lida com qualquer identificador de zona IANA.
Uma equipa de Paris quer agendar um pontapé de saída com o seu homólogo de Nova Iorque para 15 de maio de 2026 às 14:30 horário de Paris. Origem: 14:30 em 15 de maio de 2026 em Europe/Paris (CEST, UTC+2 em maio porque o horário de verão está em vigor). Destino: America/New_York (EDT, UTC-4 em maio). Origem para UTC: 14:30 - 02:00 = 12:30 UTC. UTC para destino: 12:30 + (-04:00) = 08:30 EDT. Portanto, 14:30 em Paris = 08:30 em Nova Iorque no mesmo dia, um desfasamento de 6 horas. Agora considere 15 de janeiro de 2026 às 14:30 em Paris (CET, UTC+1) → Nova Iorque (EST, UTC-5). Origem para UTC: 14:30 - 01:00 = 13:30 UTC. UTC para destino: 13:30 - 05:00 = 08:30 EST. Mesma conversão de relógio, mas apenas porque tanto Paris quanto Nova Iorque estão em horário padrão; se Paris tivesse mudado para o horário de verão e Nova Iorque não (uma situação real no final de março de cada ano), o desfasamento seria de 5 horas em vez de 6. A calculadora lida com isso de forma transparente: o usuário não precisa rastrear o horário de verão em duas zonas; a base de dados IANA faz isso por eles. Um exemplo mais dramático: 15 de dezembro de 2026 às 09:00 em Sydney (AEDT, UTC+11) → Londres (GMT, UTC+0). Origem para UTC: 09:00 - 11:00 = -02:00 UTC, que é 22:00 do dia anterior. Londres às 22:00 em 14 de dezembro — cruzando a linha de data em termos de calendário, 11 horas de diferença em termos de relógio.
Primeiro, confundir desfasamento UTC com fuso horário. "UTC+1" descreve o desfasamento; "Europe/Paris" descreve o fuso horário. Paris é UTC+1 no inverno e UTC+2 no verão. Codificar fixamente UTC+1 para "horário francês" resulta em um erro de uma hora de final de março a final de outubro. Segundo, ignorar o horário de verão. Paris e Nova Iorque observam o horário de verão, mas em horários diferentes: em meados de março, Paris ainda está em CET (UTC+1) por duas semanas, enquanto Nova Iorque já mudou para EDT (UTC-4); o desfasamento é de 5 horas em vez de 6 durante essa janela. A calculadora lida com isso; conversões manuais geralmente erram. Terceiro, misturar notação de 12 horas e 24 horas entre culturas. Os EUA e o Reino Unido usam relógios de 12 horas AM/PM coloquialmente; a Europa continental usa 24 horas. O seletor na calculadora é de 24 horas; a saída de destino também usa 24 horas para evitar ambiguidades. Quarto, agendar uma reunião sobre um cruzamento de linha de data sem perceber. Tóquio às 09:00 de terça-feira é São Francisco às 17:00 de segunda-feira — um desfasamento de 16 horas que cruza o dia do calendário. A calculadora exibe a data completa no destino, não apenas a hora, para tornar isso visível. Quinto, tratar o conversor como autoritativo para uso legal ou de aviação. A calculadora usa o tzdata do navegador, que é atualizado quando o SO é atualizado; se o usuário estiver em um sistema antigo, as regras podem estar desatualizadas para mudanças recentes de horário de verão (por exemplo, a abolição do horário de verão no Brasil em 2019, a remoção parcial do horário de verão no México em 2022). Para contextos vinculativos, sempre verifique a fonte oficial.
Fusos horários são um sistema politicamente fluido. Mudanças de horário de verão são comuns: a UE debate o fim do horário de verão desde 2018 (nenhum consenso alcançado em 2025); a Rússia aboliu o horário de verão em 2014; o México aboliu-o na maioria das regiões em 2022; o Irã aboliu-o em 2022. O projeto IANA tzdata acompanha todas essas mudanças e envia atualizações várias vezes por ano; sistemas operacionais modernos as buscam automaticamente. Desfasamentos de meia hora e um quarto de hora existem: a Índia é UTC+5:30, o Irã UTC+3:30, Newfoundland UTC-3:30, Nepal UTC+5:45, as Ilhas Chatham UTC+12:45. A calculadora lida com isso de forma transparente porque o IANA o faz. Regiões polares usam o que for administrativamente conveniente; estações antárticas podem seguir o horário de sua nação provedora. Conversões históricas (uma hora de reunião de 1956 em Berlim para Nova Iorque) também são suportadas pelo IANA, que registra todo o histórico de desfasamento para cada zona. Conversões programáticas em código devem sempre armazenar timestamps em UTC e converter para horário local apenas na exibição; esta calculadora demonstra a conversão na fronteira, onde o usuário vê o resultado.