Português (Brasil)

Ferramentas para desenvolvedores · Conversor de carimbo de data/hora Unix

Segundos ou milissegundos? Contando uma época de 10 dígitos de uma época de 13 dígitos

· Como funciona

carimbos de data/hora horário unix fluxo de trabalho do desenvolvedor

Um valor de segundos de dez dígitos e um valor de milissegundos de treze dígitos apontando para um instante
Ilustração vetorial original ToolAcre

A maioria dos valores de época que você encontra hoje tem dez dígitos (segundos) ou treze dígitos (milissegundos), e adivinhar errado coloca uma data com dezenas de milhares de anos de distância. Esta postagem explica a aritmética por trás da contagem de dígitos e por que um conversor deve indicar a unidade em vez de inferi-la.

1700000000 ou 1700000000000? — o mesmo instante escrito de duas maneiras e o painel que mostrava uma data em um futuro distante

Um valor de log de 1700000000 e um valor de carga útil de 1700000000000 podem descrever o mesmo instante. Trate o primeiro como milissegundos e seu painel cairá em janeiro 1970; trate o segundo como segundos e sua data saltará milhares de anos no futuro. Um carimbo de data/hora é apenas uma contagem mais uma unidade e um ponto de partida; portanto, uma coluna do banco de dados chamada criada_at sem documentação omitiu informações essenciais.

Por que a contagem atual de segundos tem dez dígitos — o bilionésimo segundo em 2001, o intervalo de dez dígitos até 2286 e o que nove dígitos significariam

O tempo Unix conta os segundos decorridos de 1970-01-01 00:00:00 UTC sob a convenção usual POSIX. O contador ultrapassou um bilhão em 2001; para datas positivas contemporâneas, geralmente são dez dígitos decimais. Permanecem dez dígitos até atingir dez bilhões em 2286. Esta é uma propriedade da notação de base dez, não uma regra incorporada em uma string de data ISO. Valores negativos anteriores à época e datas muito distantes do presente invalidam um simples atalho de contagem de dígitos.

Por que as contagens de milissegundos têm treze - um fator de mil, três dígitos extras e de onde vêm as convenções de JavaScript e Java

JavaScript Date.getTime() conta convencionalmente milissegundos, multiplicando o carimbo de data/hora de segundos por 1,000. Três zeros transformam uma contagem atual de dez dígitos em uma contagem de milissegundos de treze dígitos. Por exemplo, 1,700,000,000 segundos tornam-se 1,700,000,000,000 milissegundos; ambos são 2023-11-14T22:13:20.000Z. Um conversor que apenas insere separadores sem indicar a unidade assumida pode transformar um número válido numa data plausível, mas errada.

Onde a adivinhação dá errado — valores pequenos próximos à época, datas anteriores a 2001 e datas futuras em que a contagem de dígitos para de discriminar

A heurística falha perto de 1970 quando um valor de milissegundo pode ser curto, antes de 2001 quando os segundos têm menos de dez dígitos ou com contadores de microssegundos e nanossegundos. O padrão de ToolAcre é interpretar magnitudes abaixo de 10¹¹ como segundos e valores maiores como milissegundos e rotula a unidade usada. Esse limite é uma suposição prática, não um decodificador de formato inequívoco. Um carimbo de data/hora fornecido por um API específico deve ser interpretado usando a documentação desse API mesmo quando seu comprimento for incomum.

Exemplo resolvido: três valores de um log — 1700000000, 1700000000000 e 1700000000000000, lidos em segundos, milissegundos e microssegundos

Três inteiros de um log ilustrativo mostram a armadilha. Interprete 1700000000 como segundos e 1700000000000 como milissegundos: ambos são resolvidos como 2023-11-14T22:13:20Z. Interprete 1700000000000000 como microssegundos e divida por um milhão para obter a mesma contagem de segundos. O conversor ToolAcre aceita segundos ou milissegundos, não um modo de microssegundos: colar esse terceiro número sem converter sua unidade primeiro não confirmará o instante pretendido. Sempre mantenha o campo bruto e sua unidade juntos durante a depuração.

Por que a unidade deve ser declarada, não adivinhada - como o conversor mostra a unidade aplicada para que uma suposição errada seja visível em vez de silenciosa

Um serviço que envia carimbos de data/hora deve nomear a unidade em seu esquema ou usar o texto ISO 8601 com um deslocamento explícito. Se um campo legado não estiver documentado, compare vários valores com outro horário de evento confiável antes de decidir; uma única data coincidentemente plausível é evidência insuficiente. O conversor exibe qual unidade foi aplicada, dando a você a chance de detectar um erro de fator 1,000. Altere a unidade explicitamente e compare, em vez de confiar em uma estimativa automática como um contrato API de longo prazo.

O que isso não cobre - carimbos de data e hora armazenados como strings, ISO 8601 texto ou datas seriais de planilhas, que são problemas diferentes

Este artigo não explica datas seriais do Excel, strings como 2026-09-28T10:15Z ou formatação de fuso horário das leituras do relógio local. São representações diferentes. Os carimbos de data/hora Unix referem-se a um instante; o mesmo instante aparece como diferentes horários de relógio de parede em zonas diferentes. As convenções de segundos bissextos também merecem tratamento separado, e um contador assinado de 32 bits tem um problema de estouro em 2038 que é distinto da questão de segundos versus milissegundos.

Conclusão: conte os dígitos e confirme a unidade - e como o conversor de carimbo de data / hora Unix lê segundos e milissegundos com a unidade rotulada

Conte os dígitos como uma dica inicial e depois confirme a unidade declarada pelo produtor e pelo menos um evento conhecido. O conversor de carimbo de data / hora Unix torna visível a suposição de segundos/milliseconds aplicada e imprime UTC e representações locais em seu navegador. Não deixe que uma data bonita substitua a documentação contrária do sistema que produziu o valor.