Calculadora de fuso horário
Resultado
Hora no destino
- Data no destino
- 14 de janeiro de 2026
- Dia da semana no destino
- quarta-feira
- Fuso UTC de origem
- UTC+08:00
- Fuso UTC de destino
- UTC-05:00
- Diferença em relação à origem
- -13,00 horas
- Mudança de dia
- -1
A calculadora de fuso horário converte uma data e um horário de um fuso para outro e mostra como aquele momento fica do outro lado: o horário local, a data, o dia da semana e se você caiu no dia anterior ou no seguinte. Os dois deslocamentos em relação ao UTC são impressos ao lado do resultado, então a diferença de fuso horário entre duas cidades é um número que se lê em vez de um que se calcula, e as regras de horário de verão em vigor naquela data exata já estão aplicadas. É o que você quer antes de marcar uma reunião entre fusos horários, antes de perguntar que dia é lá, ou quando um carimbo de data e hora chega de outro lugar e precisa ser colocado no seu calendário.
Fórmula
tempo no destino = data e tempo de origem − fuso UTC de origem + fuso UTC de destino; diferença de fuso = fuso de destino − fuso de origem; mudança de dia = data de destino − data de origem
- Data
- O dia de calendário na origem, escrito como AAAA-MM-DD. É o dia de lá, e não o dia de onde você está lendo isto
- Tempo
- O relógio na origem, como HH:MM ou HH:MM:SS em formato de 24 horas. Os segundos podem ser omitidos; eles aparecem sempre no resultado
- Fuso horário de origem
- O fuso ao qual pertence o horário que você digitou. Um de 22 fusos da base IANA, cada um rotulado pela sua cidade em vez do seu deslocamento, porque o deslocamento é propriedade do momento e não do lugar
- Fuso horário de destino
- O fuso para o qual converter. Os mesmos 22 fusos da lista de origem
- Hora no destino
- O relógio no fuso de destino, sempre com segundos. É o resultado principal
- Data no destino
- A data de calendário no fuso de destino, que nem sempre é a data que você digitou — é justamente para isso que existe a mudança de dia
- Dia da semana no destino
- O dia da semana no fuso de destino, pelo nome, e calculado para a data de destino e não para a de origem
- Fuso UTC de origem
- A distância do fuso de origem até o UTC no instante resolvido, impressa como UTC+HH:MM ou UTC-HH:MM
- Fuso UTC de destino
- A distância do fuso de destino até o UTC no mesmo instante. Os dois deslocamentos são lidos no momento convertido, então os dois já incluem o horário de verão se ele estiver em vigor ali
- Diferença em relação à origem
- O deslocamento de destino menos o de origem, em horas. Negativo significa que o destino está atrás da origem
- Mudança de dia
- -1, 0 ou +1: se a data de destino é o dia anterior, o mesmo dia, ou o dia seguinte ao que você informou
Use sempre que duas cidades estiverem envolvidas e um relógio precisar ser confiável: marcar uma chamada do outro lado do oceano, conferir se um voo chega no mesmo dia em que saiu, ler um log de servidor escrito em UTC, ou entender por que o domingo de manhã de alguém é o seu domingo à noite. A diferença de horário entre cidades não é fixa, e é aí que as pessoas erram na mão, porque não é uma propriedade do par de cidades: os mesmos dois fusos diferem em 12 horas em janeiro e em 11 em julho. Esta página converte um instante que você já tem; ela não descobre em que fuso um lugar está (as listas são fixas em 22 fusos) e não diz nada sobre tempos de viagem, duração de voo ou lembretes de compromisso.
Exemplos resolvidos
Meio-dia em Xangai para Nova York — o dia anterior
- Xangai está em UTC+08:00 em janeiro, então o meio-dia lá são 04:00 UTC de 15 de janeiro
- Nova York está no horário padrão, UTC-05:00, então 04:00 UTC lê 23:00:00 no relógio de lá
- 23:00 está atrás da meia-noite, o que põe a data em 14 de janeiro — um dia antes do informado, e a linha da mudança de dia diz isso com -1
- 14 de janeiro de 2026 é uma quarta-feira, e é esse o dia da semana que o painel escreve, por extenso
- Os dois deslocamentos diferem em -13,00 horas: 08:00 − (−05:00) são 13 horas, e o destino é o que fica mais a oeste
É o estado padrão da calculadora e o caso que mais surpreende: uma mensagem enviada na hora do almoço em Xangai chega a Nova York no dia de calendário anterior. Fazer isso na mão com uma regra única de que Xangai está 12 ou 13 horas à frente é onde o erro entra — a resposta aqui é 13, mas em julho seria 12, porque Nova York está em horário de verão e Xangai não.
Um horário que não existe: Nova York, 8 de março de 2026, 02:30
- Os relógios de Nova York avançam às 02:00 locais nesta data, então 02:00 vira 03:00 e a meia hora de 02:00 a 03:00 nunca acontece
- O 02:30 digitado, portanto, não existe. A página o lê como as regras da IANA prescrevem para uma lacuna: empurra para a frente, o que dá 03:30 EDT
- 03:30 de 8 de março de 2026 é um domingo, e o painel escreve domingo na linha do dia da semana
- Como o instante resolvido já está em EDT, o deslocamento de origem impresso é UTC-04:00 — e não o UTC-05:00 que 02:30 carregaria no dia anterior
- Xangai está em UTC+08:00, doze horas à frente do EDT, então 03:30 vira 15:30:00 do mesmo dia
O deslocamento impresso ao lado de um horário digitado pode parecer errado até você ver por quê: 02:30 em Nova York é uma leitura de relógio em UTC-05:00 no inverno, mas este 02:30 em particular cai na lacuna depois da virada, então o instante em que ele se resolve é um instante de EDT e reporta UTC-04:00. A página lê lacunas e sobreposições do mesmo jeito que a base de dados de fusos da IANA prescreve, e nunca recusa a entrada — então o número sai sempre, e este é o caso que vale ler duas vezes.
As duas pontas em horário de verão: Londres para Los Angeles em 4 de julho
- Em julho Londres está no horário de verão britânico, UTC+01:00, então 09:30 lá são 08:30 UTC
- Los Angeles está no horário de verão do Pacífico, UTC-07:00, então 08:30 UTC lê 01:30:00 no relógio de lá
- Os deslocamentos diferem em 8 horas, e não são as mesmas 8 horas que se esperaria no inverno: em janeiro Londres está em UTC+00:00 e Los Angeles em UTC-08:00
- Os dois deslocamentos impressos incluem o horário de verão de cada uma, e é por isso que a origem lê UTC+01:00 em vez de UTC+00:00
- A data não muda, então a mudança de dia é 0 — e 4 de julho de 2026 é um sábado, o que o painel escreve por extenso na linha do dia da semana
Responder isso com os deslocamentos padrão (0 e -08:00) dá a mesma diferença de 8 horas e o mesmo horário, e é exatamente por isso que o erro é fácil de não ver aqui e aparece nas datas de cada lado de uma transição. As duas cidades mudando em direções opostas na mesma semana de março é quando uma regra de deslocamento fixo erra por uma hora inteira.
Ano-novo em Auckland, ainda o ano passado em UTC
- Auckland está no horário de verão da Nova Zelândia em janeiro, UTC+13:00, então a meia-noite lá são 11:00:00 UTC de 31 de dezembro de 2025
- Converter para UTC, portanto, atravessa ao mesmo tempo uma fronteira de dia e uma de ano
- A data de destino é 31 de dezembro de 2025, e a mudança de dia de -1 é calculada subtraindo números de dia em vez de comparar textos de data
- 31 de dezembro de 2025 é uma quarta-feira, que é o que a linha do dia da semana escreve
- A diferença em relação à origem é -13,00 horas: o destino, o UTC, é o que fica mais a oeste
A mudança de dia não é a regra simples de que o oeste está sempre um dia atrás. Aqui -13,00 horas atravessa a meia-noite; as mesmas -13,00 horas entre Xangai e Nova York também caem no dia anterior, enquanto uma diferença de -5 horas de Londres para Nova York não cai. O dia da semana é reportado para a data de destino, e é por isso que ele diz quarta-feira quando a data informada era uma quinta.
Limitações
A calculadora cobre de 1970 a 2100 e 22 fusos horários, e não todos os que a base de dados da IANA conhece. A janela é deliberada: antes de 1970 a base registra o horário médio local que um lugar de fato mantinha — Xangai era UTC+08:06, Monróvia usava um deslocamento com segundos — e respostas assim são corretas mas parecem defeito. Horários ambíguos e inexistentes são resolvidos como as regras da IANA prescrevem (empurrados para a frente numa lacuna de horário de verão, tomando a leitura mais antiga das duas numa sobreposição de outono) em vez de serem recusados; a página não avisa que isso aconteceu, então as datas em volta de uma transição merecem ser conferidas contra os deslocamentos mostrados. Nenhum fuso é deduzido do nome de lugar que você digita, porque não há onde digitar: as duas listas são fixas. A página não sabe em que fuso o seu aparelho está, não faz durações nem tempos de voo, e não inclui segundos intercalares — o cálculo trata o UTC como uma escala uniforme, que é como o tempo Unix funciona, e isso é coisa diferente dos segundos intercalares que de fato são inseridos no UTC de tempos em tempos. Os três campos de texto — o horário de destino e os dois deslocamentos UTC — saem exatamente como um sistema os escreve: 23:00:00, UTC+08:00, UTC-05:00. Não há separador de milhar nem vírgula decimal a aplicar neles, porque não são números formatados; a diferença em horas e a mudança de dia, que são números, seguem a grafia brasileira, como em -13,00 e -1.
Perguntas frequentes
- Qual é a diferença de horário entre duas cidades?
- A diferença de horário entre cidades não é um número fixo, e a diferença em relação à origem que esta página imprime é a que está em vigor na data informada. Dois fusos podem diferir em 13 horas em janeiro e em 12 em julho, porque um deles adota horário de verão e o outro não. Então a pergunta sobre a diferença entre duas cidades só tem resposta com uma data junto, e é por isso que o campo de data faz parte da pergunta aqui em vez de ser um extra opcional.
- Como calculo o horário de uma reunião entre fusos horários?
- Coloque a reunião no fuso em que ela foi proposta e converta para cada um dos outros fusos, um de cada vez. Numa reunião entre fusos horários o número útil costuma ser a mudança de dia, e não a hora: uma chamada às 09:00 em Londres são 18:00 em Tóquio no mesmo dia, mas 04:00 em Nova York, e é esse 04:00 que decide se o convite é razoável. Como a página informa também o dia da semana e a data, você vê quando uma proposta caiu no fim de semana do outro lado.
- A calculadora aplica o horário de verão automaticamente?
- Sim, nos dois fusos, e para a data exata em vez de para hoje. O horário de verão não é propriedade de um fuso, e sim de um momento: os deslocamentos impressos são os que as regras da IANA dão para o instante que está sendo convertido, então uma data de janeiro e uma de julho entre os mesmos dois fusos podem sair com uma hora de diferença. Nada é suposto sobre a data de hoje, o que significa que um resultado calculado para março do ano que vem já inclui a transição daquele março.
- Por que o deslocamento UTC às vezes não é o que eu esperava?
- Porque o deslocamento mostrado pertence ao instante em que a entrada se resolveu, e não ao relógio que você digitou. No dia em que os relógios avançam, a hora que foi pulada não existe, e um horário digitado dentro dela é lido como o momento logo depois — então um 02:30 informado para Nova York num dia de transição de março reporta UTC-04:00 (EDT) e não o UTC-05:00 que 02:30 carregava no dia anterior. As duas leituras são do mesmo instante; só uma delas é o deslocamento em vigor naquele momento.
- Que dia é lá quando aqui é quarta-feira?
- Depende da hora além dos fusos, e é por isso que esta página pede as duas coisas. Atravesse a linha de data para leste e você ganha um dia; converta para oeste por horas suficientes e você perde um. O campo da mudança de dia responde direto com -1, 0 ou +1, e o campo do dia da semana nomeia o dia no destino, então dá para saber se o outro lado já chegou ao dia sobre o qual você está perguntando. Um exemplo local: das 12:00 em São Paulo (UTC-03:00 o ano inteiro, já que o Brasil não tem mais horário de verão desde 2019) saem 15:00 em Londres em janeiro, com três horas de diferença.
Referências
- IANA Time Zone Database — Internet Assigned Numbers Authority
- Theory and pragmatics of the tz code and data — IANA — the source for the 1970-01-01 accuracy window this page states
- Temporal documentation — Time zone handling — TC39 — describes the 'compatible' disambiguation rule this page follows