Um deslocamento (offset) como +01:00 diz a que distância do UTC um relógio está em um momento específico. Um fuso horário como Europe/Madrid é o conjunto de regras que decide qual deslocamento vale em cada data, passada e futura. Numa linha de log eles parecem iguais, mas só o fuso consegue responder "qual será o deslocamento em julho do ano que vem?", e só o fuso sobrevive a um governo mudando de ideia. Se você guarda o deslocamento onde precisava do fuso, essa informação se perde e não dá para recuperá-la a partir do número.
Qual é a diferença entre um deslocamento e um fuso horário?
Um deslocamento é uma medição. Madri em janeiro é +01:00; Madri em julho é +02:00. A mesma cidade, o mesmo fuso, dois deslocamentos. O nome do fuso é o que sabe o porquê: ele guarda o deslocamento padrão, a regra de quando o horário de verão começa e termina, e a história de todas as vezes em que essas regras foram diferentes.
| Deslocamento | Fuso horário | |
|---|---|---|
| Exemplo | -03:00, +05:30 | America/Argentina/Buenos_Aires, Asia/Kolkata |
| É | um número, válido para um instante | o nome de um conjunto de regras |
| Muda com o horário de verão | sim, o próprio número muda | não, o nome fica e as regras produzem um número novo |
| Consegue dizer o deslocamento do mês que vem | não | sim, se as regras não tiverem mudado até lá |
| É compartilhado por vários lugares | sim, muitos fusos têm +01:00 agora mesmo | não, um nome por região com sua própria história |
Dois lugares podem compartilhar um deslocamento hoje e ainda assim ser fusos diferentes. Os relógios deles coincidem esta semana e divergem na primavera, porque um se move e o outro não. O deslocamento não os distingue. O nome distingue.
Por que não dá para descobrir o fuso a partir do deslocamento?
Porque o mapeamento só vai em um sentido. Muitos fusos têm -03:00 em algum momento; um -03:00 solto não revela nenhum deles. As abreviações são piores: CST é usada para a hora padrão central dos Estados Unidos, a hora padrão da China e a hora padrão de Cuba, e nada nas três letras diz qual. Trate uma abreviação como enfeite para um leitor humano, não como dado.
O sentido contrário funciona, mas só para uma data. Dê um nome de fuso e um instante e você obtém exatamente um deslocamento. Dê um deslocamento e você não obtém nada sobre nenhum outro instante.
O que um fuso sabe que um deslocamento não sabe?
Tudo o que um legislativo já decidiu sobre relógios. As regras são escritas por governos, e governos as mudam, às vezes com semanas de aviso. Os Estados Unidos ampliaram o horário de verão a partir de 2007. O México aboliu o horário de verão para a maior parte do país em 2022. A Argentina está há anos em -03:00 o ano todo, enquanto Europe/Madrid continua oscilando entre +01:00 e +02:00. Alguns fusos ficam fora da hora cheia: Asia/Kolkata é +05:30 e o Nepal é +05:45.
O software não deixa essas regras escritas no código. Ele as lê do banco de dados de fusos horários da IANA, que é atualizado várias vezes por ano justamente porque as regras não param de mudar. Um celular antigo ou um servidor que nunca foi atualizado pode estar errado sobre um fuso cuja regra mudou depois da última atualização dele, e nenhum código seu resolve isso a não ser atualizando os dados.
É por isso também que o deslocamento que você obtém para uma data distante no futuro é uma previsão, não um fato. Pegue "9h em Madri no dia 15 de julho de 2031". As regras de hoje dizem +02:00. Se elas mudarem antes disso, essa mesma hora de relógio passa a ser um instante diferente.
Quando um deslocamento perde informação de que você precisa?
Sempre que a pergunta for sobre uma hora que ainda não aconteceu, ou sobre uma hora de relógio de parede e não de um log. Uma "hora" pode significar duas coisas diferentes, e cada uma pede um armazenamento diferente.
- Algo que já aconteceu (um pagamento, um login, uma linha de log). É um instante. Guarde como um timestamp UTC, ou como uma string ISO 8601 com deslocamento. Aqui o deslocamento serve, porque o momento é fixo e ninguém vai pedir para você recalculá-lo.
- Algo que uma pessoa agendou (uma reunião às 09:00, um voo, uma loja que abre às 10:00). É uma hora de relógio em um lugar. Guarde a data e a hora locais mais o nome do fuso, e calcule o instante quando precisar.
Se você guardar o segundo tipo como um instante UTC, vai estar certo até as regras mudarem. Digamos que você marque uma reunião na terça às 09:00 em Madri e a guarde como 07:00 UTC, porque foi isso que o deslocamento deu no verão. Se a reunião for em novembro, quando Madri está em +01:00, o calendário passa a mostrá-la às 08:00 para todo mundo em Madri. Nada estava errado na hora de guardar. O fuso teria sabido; o deslocamento não podia.
Guardar só o deslocamento falha do mesmo jeito com eventos recorrentes. "Toda segunda às 09:00, +01:00" está certo até os relógios adiantarem, e depois disso dispara uma hora fora da hora local durante metade do ano.
O que dá errado duas vezes por ano e o que o relógio local pula?
Quando os relógios adiantam, um trecho de hora local não existe. Quando atrasam, um trecho acontece duas vezes. Em um fuso que muda às 02:00 na primavera, as 02:30 não aparecem naquele dia no relógio de parede. No outono, a 01:30 aparece duas vezes, com uma hora de diferença, com dois deslocamentos diferentes.
Então uma hora local sem deslocamento pode ser inválida, ou pode nomear dois instantes. Por isso "1º de novembro de 2026, 01:30, Nova York" não basta para identificar um momento nos dias em que os relógios mudam, e por isso os bancos de dados que aceitam uma hora local com um nome de fuso precisam de uma regra para essas horas. É também por isso que uma duração de "24 horas" e "um dia" não são a mesma coisa nessas duas datas, a mesma armadilha que faz contar os dias entre duas datas depender do que você conta.
O que o conversor de timestamp consegue mostrar e o que não consegue?
Cole um timestamp no conversor de timestamp Unix e a linha "ISO 8601 (deslocamento local)" dá o deslocamento que o fuso do seu dispositivo tinha naquele momento, ao lado da linha UTC. Teste um de janeiro e um de julho e o deslocamento local muda enquanto o fuso não. Essa é a diferença em uma só tela, e nada sai da página.
O que ele não faz importa aqui. Ele só tem dois fusos, o seu e o UTC, sem seletor, então não consegue dizer o que um momento é em Madri a não ser que você esteja em Madri. Ele mostra o nome do fuso do seu dispositivo mas não deixa você digitar um. E na direção de data para timestamp, ele pede uma hora local sem deslocamento e depois usa o seu navegador para resolvê-la. Para as horas puladas e repetidas acima, ele não avisa que a hora era inválida ou ambígua; o navegador escolhe uma leitura em silêncio. Conferir um dia de mudança de horário fica por sua conta.
O mesmo limite vale para datas antigas. Horários locais anteriores a 1970 dependem de dados históricos de fuso que o seu navegador pode não ter por completo, então um horário local convertido anterior a 1970 pode estar desviado. A linha UTC não é afetada.
O que você deve guardar?
- Para um evento que aconteceu: um timestamp UTC. Se quiser também a visão local, guarde o nome do fuso em que ele aconteceu como um campo separado, não embutido na hora.
- Para um evento que uma pessoa agendou: a data local, a hora local e o nome do fuso, como três campos. Calcule o instante no último momento possível.
- Para uma data sem hora (um aniversário, a data de uma fatura): um simples
YYYY-MM-DDe nenhum fuso. Um timestamp Unix é o tipo errado para isso. - Nunca a abreviação de três letras como dado, e nunca um deslocamento no lugar de um fuso.
Guarde o deslocamento além do nome do fuso se quiser um registro de qual era o deslocamento naquele momento. Isso é útil para trilhas de auditoria. Não substitui o nome.
Para ver a diferença por conta própria, coloque um timestamp de janeiro e um de julho no conversor de timestamp Unix e compare o deslocamento local de cada um. Lembre-se de que ele só mostra o fuso do seu próprio dispositivo e o UTC, então não substitui um seletor de fusos de verdade.
Se quiser a outra metade da história, o que é um timestamp Unix explica por que um instante não precisa de fuso nenhum, que é exatamente o motivo pelo qual uma hora de relógio agendada precisa de um guardado ao lado.
Perguntas frequentes
Qual é a diferença entre um fuso horário e um deslocamento UTC?
Um deslocamento UTC, como +01:00, é um único número que diz a que distância do UTC um relógio está em um momento específico. Um fuso horário, como Europe/Madrid, é um conjunto de regras com nome que decide qual deslocamento vale em cada data, incluindo o horário de verão e mudanças passadas. Um mesmo fuso produz deslocamentos diferentes ao longo do ano.
Devo guardar um fuso horário ou um deslocamento no meu banco de dados?
Depende do que a hora significa. Para algo que já aconteceu, guarde um timestamp UTC; o deslocamento é opcional. Para algo que uma pessoa agendou em um lugar, como uma reunião ou um voo, guarde a data e a hora locais junto com o nome do fuso, porque o deslocamento pode mudar antes de o evento acontecer.
Posso descobrir o fuso horário a partir de um deslocamento UTC?
Não. Muitos fusos diferentes compartilham o mesmo deslocamento em um dado momento, e podem divergir em outras épocas do ano. Um deslocamento só reduz a resposta a uma lista de candidatos. Você precisa do nome do fuso, ou de uma localização, para conhecer as regras.
Por que as regras dos fusos horários mudam?
Quem as define são os governos, e os governos as mudam por motivos de energia, política ou economia, às vezes com pouco aviso. O software lê as regras do banco de dados de fusos horários da IANA, que é atualizado várias vezes por ano. Um sistema que não aplicou a última atualização pode estar errado sobre um fuso cuja regra mudou recentemente.
EST ou CST são um fuso horário?
São abreviações, não identificadores. CST sozinha pode significar hora padrão central dos Estados Unidos, hora padrão da China ou hora padrão de Cuba, e as letras não dizem qual. Para dados use um nome IANA como America/Chicago, e trate a abreviação como texto para um leitor humano e nada mais.
Última atualização 29 de setembro de 2026
