Milissegundos para data: UTC vs hora local, e por que pode parecer errado

Ultima revisao 2026-05-05. O conversor gratuito de milissegundos para data recebe um timestamp Unix em milissegundos e retorna uma data e hora legiveis. A maior parte da confusao do leitor nao e sobre a conversao em si - e sobre qual fuso horario a string legivel representa. Este guia nomeia os quatro valores que voce sempre deve ler juntos e da uma verificacao de sanidade de 30 segundos para que voce nunca envie uma data que esteja horas errada.

Por que o mesmo timestamp mostra datas diferentes

Um timestamp Unix em milissegundos conta os milissegundos decorridos desde o epoch Unix, fixado em 1970-01-01T00:00:00 UTC. O numero nao carrega um fuso horario ou um calendario. Cada sistema que o exibe escolhe seu proprio fuso para a saida legivel: seu navegador usa o locale do SO, um servidor usa o locale de seu container, um banco SQL usa o fuso da sessao, e um log JSON usa o que o gravador formatou. O conversor de milissegundos para data mostra tanto UTC quanto sua hora local para que voce possa ver o offset de relance.

Os quatro valores para sempre ler juntos

• O numero original (1713538800000) - sem fuso. Armazene isto em bancos de dados, envie por APIs HTTP, registre em logs. Ele nunca desvia.
• Data/hora UTC (2024-04-19T15:00:00Z) - a renderizacao canonica. Use em logs de auditoria, relatorios entre regioes, e qualquer coisa compartilhada entre equipes.
• Data/hora local (2024-04-19 22:00:00 +07:00) - o que o usuario final ve. Use para e-mails, convites de calendario e exibicoes para o leitor.
• ISO 8601 com offset (2024-04-19T22:00:00+07:00) - seguro para ida e volta. Inclui hora local e offset, entao um parser downstream pode recuperar o momento exato.

Verificacao de sanidade de 30 segundos antes de enviar uma data

1. Confirme que a entrada esta em milissegundos, nao em segundos. Um numero de 13 digitos e milissegundos; um numero de 10 digitos e segundos. Veja numero longo - milissegundo ou segundo? para as regras.
2. Note o valor UTC que o conversor retorna. Esta e a resposta canonica e sem fuso.
3. Adicione o offset local ao UTC (ex.: +07:00 para Bangkok, -08:00 para Los Angeles, com horario de verao). O valor local deve coincidir.
4. Se o valor local discordar, o fuso do seu SO esta diferente do que voce assumiu. Ajuste o SO ou interprete o UTC diretamente.

UTC vs local na pratica

Use UTC para armazenamento e transporte. Colunas de banco de dados, JSON sobre HTTP, arquivos de log, trilhas de auditoria. Valores UTC nao desviam atraves de transicoes de horario de verao e nao variam por regiao de implantacao.

Use hora local apenas para exibicao. Convites de calendario, e-mails para usuarios, lembretes. Converta para local na camada de renderizacao, nao no armazenamento. A mesma linha de banco deve renderizar como 22:00 hora de Bangkok e 08:00 hora de LA - isso esta correto, nao e um bug.

Use ISO 8601 com offset para os casos intermediarios. Quando voce envia um valor para um sistema downstream que pode nao conhecer o fuso do usuario, prefira a forma ISO com offset incluido. Evite texto livre "19 de abril as 22h" - nao e parseavel.

Guias complementares

• Numero longo - milissegundo ou segundo? - desambiguacao de entrada.
• Timestamps Unix explicados - o que e o epoch e de onde vem o formato.
• Conversor de milissegundos para data - a propria ferramenta.
• Obter hora atual em milissegundos - a direcao inversa.

Perguntas frequentes

Por que o conversor mostra duas horas diferentes para a mesma entrada?

Sao o mesmo instante em fusos horarios diferentes. O numero nao tem fuso; o valor UTC e a renderizacao canonica e o valor local e o mesmo instante visto do fuso do seu SO. A diferenca e o offset local.

A hora local parece errada - como conserto?

A hora local e o que quer que o seu SO informe como o fuso atual. Se seu laptop esta definido para Singapura mas voce espera Bangkok, o valor local estara uma hora errada. Ajuste o fuso do SO, ou interprete o valor UTC e aplique o offset que voce realmente quer.

O horario de verao muda a conversao?

Sim - para qualquer fuso que observa horario de verao, o offset local muda uma hora duas vezes por ano. O valor UTC nunca muda. Dois timestamps de lados opostos de uma transicao de horario de verao parecem uma hora distantes em hora local mesmo quando os milissegundos decorridos estao corretos.

Posso armazenar hora local diretamente no meu banco de dados?

Sim, mas raramente uma boa ideia. Armazenar UTC e renderizar local no local de leitura e canonico; sobrevive a mudancas de servidor, mudancas de regiao e transicoes de horario de verao. Armazenar hora local forca cada leitor a saber em qual fuso o gravador estava - geralmente perdido.

Algo e enviado para um servidor?

A conversao roda no seu navegador; a entrada em milissegundos e as strings resultantes ficam no seu dispositivo. Isso importa quando o timestamp identifica um evento sensivel que voce nao quer registrar.