Timestamps Unix: segundos, milissegundos e a data errada

Um carimbo de tempo que cai em janeiro de 1970 geralmente tem a unidade errada. O número 1792069200 é em segundos Unix; 1792069200000 é o mesmo instante em milissegundos. Nenhum deles exige que você adicione um deslocamento de fuso antes de converter.

Abra o Conversor de fuso, expanda Colar uma data ou carimbo de tempo, cole qualquer um dos números e escolha Converter. Verifique a interpretação abaixo do formulário. Ambos devem produzir 2026-10-15T13:00:00.000Z.

Quatro maneiras de escrever o mesmo momento

Experimente uma de cada vez, ou baixe os quatro exemplos de carimbo de tempo:

1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00

A última linha já é meia-noite do dia seguinte, mas ainda representa o mesmo momento. O deslocamento explícito de onze horas explica a diferença.

A ferramenta lê o primeiro número como segundos e o segundo como milissegundos. Para datas próximas de hoje, 10 versus 13 dígitos é uma pista útil, não uma definição universal de carimbo de tempo. Este conversor rejeita entradas numéricas de 11 e 12 dígitos em vez de adivinhar. Ele suporta datas de 1900 a 2100; não é um parser para todos os formatos históricos de carimbo de tempo.

Se você escreve em JavaScript, o construtor numérico Date espera milissegundos. A referência de Date da MDN documenta essa unidade. Multiplicar segundos por 1.000 é uma conversão de unidade, não um ajuste de fuso.

Verifique a data e também o relógio

Use Adicionar fuso para incluir as cidades que você precisa. Para o exemplo acima, os resultados testados são:

Esses deslocamentos pertencem à data de exemplo. Não os reutilize como diferenças permanentes entre cidades; o horário de verão pode mudar a diferença. Para uma tarefa recorrente, veja o exemplo de cron e horário de verão.

Arrastar dentro de qualquer cartão de relógio move o momento compartilhado, então todos os cartões atualizam juntos. Copiar todos os horários copia também as datas e os deslocamentos. Isso é mais útil para um colega do que enviar apenas "9h".

Uma data sem deslocamento é uma entrada diferente

Cole 2026-10-15T13:00 e defina Sem fuso horário, interpretar como para Australia/Melbourne. Isso se torna 2026-10-15T02:00:00.000Z, onze horas antes do nosso primeiro exemplo.

Nada quebrou: desta vez você forneceu uma leitura de relógio local, e o fuso de origem forneceu o contexto ausente. Com um número Unix ou um deslocamento explícito, essa seleção de origem não move o instante. Meu fuso pode adicionar o fuso do seu dispositivo, mas seu dispositivo não pode dizer qual fuso uma entrada de log sem rótulo usou originalmente.

Resolva entradas ambíguas antes de compartilhar

A ferramenta pede deliberadamente que você esclareça várias entradas:

• 10/11/2026 09:00 pode significar 11 de outubro ou 10 de novembro. Use uma data ano-mês-dia.
• 2026-10-15 09:00 CST usa uma abreviação ambígua. Escolha um fuso de origem completo ou forneça um deslocamento UTC explícito.
• 2026-11-01T01:30 em America/New_York ocorre duas vezes quando os relógios atrasam. Forneça o deslocamento pretendido; uma leitura de relógio local sozinha não pode escolher entre eles.

Verificamos essas entradas e os quatro carimbos equivalentes com o parser da ferramenta em 15 de outubro de 2026. A saída da conversão e o registro de resultados preservam os valores exatos. A interpretação de linguagem natural varia por idioma; uma data e um deslocamento explícitos são a melhor escolha quando o horário precisa ser inequívoco.