Português (Brasil)

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

Nem toda época é 1970: NTP, Windows FILETIME, GPS e datas do Excel

· Fundo

carimbos de data/hora formatos de dados depuração

Várias linhas de tempo com diferentes pontos zero convergindo em um instante
Ilustração vetorial original ToolAcre

A origem 1970 do Unix é apenas uma entre muitas. Esta postagem pesquisa as épocas que você encontrará em arquivos e protocolos (1900, 1601, 1904, 1980, 2001) e mostra como reconhecer um valor que nunca foi o tempo Unix.

O carimbo de data/hora que chegou em 1900 — um valor de uma captura de rede que nenhuma escolha de unidade poderia tornar sensata

Um número de uma captura de pacote pode produzir absurdos tanto em segundos quanto em milissegundos porque a unidade não é o único parâmetro oculto. Época significa um ponto zero escolhido; Unix usa 1970, enquanto outro protocolo pode contar de outro lugar. O reescalonamento não pode reparar a origem errada.

Quando ambas as leituras de ToolAcre entrarem em conflito com o horário do evento conhecido, pare de alternar. Identifique o nome do campo, produtor, versão do protocolo e origem documentada. Cortar repetidamente os dígitos até que apareça um ano plausível converte a investigação em coincidência.

O mesmo diagnóstico se aplica quando uma data sensata aparece, mas entra em conflito com os eventos circundantes. A plausibilidade é uma verificação fraca; a proveniência e um evento de referência conhecido são mais fortes.

NTP e 1900 — segundos desde 1900-01-01 com uma fração de 32 bits e o rollover 2036 que ela traz

A pasta de trabalho forneceu a origem de NTP, layout fracionário e data de rollover. Nenhum é implementado ou testado no conversor Unix, portanto este artigo não certifica essas especificações. Uma captura de rede deve ser decodificada de acordo com a documentação do protocolo usada pelo remetente e pelo analisador.

Somente após derivar os segundos Unix o valor deve entrar nesta ferramenta. Mantenha o contexto de era ou rollover porque um campo de largura fixa pode não identificá-lo sozinho. Um resultado UTC polido de uma era presumida pode ser internamente consistente e externamente errado.

Os campos de protocolo também podem dividir componentes inteiros e fracionários. Concatená-los ou decimalizá-los sem a escala especificada cria um novo número que nenhum decodificador compatível pretendia.

NTP detalhes de conversão e comportamento de rollover exigem documentação de origem não presente aqui

Da mesma forma, os contadores nomeados Windows e .NET não são modos aceitos. O repositório não contém constantes para suas origens ou escalas de escala. Seus grandes valores decimais podem exceder o intervalo exato de números inteiros de JavaScript antes que um desenvolvedor tente a conversão.

Use uma biblioteca segura para números inteiros baseada na definição documentada da plataforma, preserve o original como texto ou número inteiro amplo e, em seguida, emita um valor Unix. Não subtraia um deslocamento lembrado em ponto flutuante. A exatidão no nível inferior é importante quando a resolução da fonte é menor que milissegundos.

Um teste de ida e volta deve incluir um valor com dígitos subsegundos diferentes de zero. Os fixtures de segundos inteiros não podem expor se o restante de 100-nanossegundos ou milissegundos foi preservado corretamente.

As definições FILETIME e .NET não são implementadas por ToolAcre e não são declaradas na memória

As datas da planilha apresentam uma representação diferente: uma série numérica interpretada pelas configurações do sistema de datas da pasta de trabalho. A peculiaridade 1900 da pasta de trabalho e a reivindicação mais antiga do Mac exigem fontes de planilhas e não são estabelecidas aqui. ToolAcre não lê metadados da pasta de trabalho.

Inspecione o arquivo com ferramentas compatíveis com planilhas, determine o sistema de data configurado e preserve a precisão dos dias fracionários usando essa biblioteca. Tratar uma série como segundos Unix pode produzir uma data 1970 antecipada que parece um bug de escala comum, enquanto o problema real é a origem e a unidade juntas.

As configurações da pasta de trabalho podem acompanhar um arquivo, portanto, duas séries visualmente semelhantes podem usar origens diferentes. A conversão pertence ao limite do documento onde os metadados estão disponíveis.

Sistemas seriais de planilhas e peculiaridades exigem evidências específicas de planilhas

GPS e épocas relacionadas à Apple mencionadas no esboço também estão fora da implementação. Suas relações podem envolver convenções de escala além de uma constante mudança de origem. Nenhuma fórmula atual de compensação ou conversão é publicada aqui sem evidências oficiais.

O diagnóstico geral ainda transfere: identificação do zero, duração do tick e convenção do salto do produtor. Em seguida, converta com uma biblioteca apropriada e verifique um carimbo de data/hora conhecido do mesmo conjunto de dados. Três fatos independentes são mais seguros do que uma estimativa de largura decimal.

Esse cuidado é particularmente importante em torno de convenções bissexuais. Uma constante que funcione para uma escala e data pode não ser uma relação atemporal entre todos os pares de sistemas.

Os relacionamentos GPS e Apple Epoch exigem fontes autorizadas fora deste módulo

Um método defensável funcionado começa com um instante conhecido, por exemplo o `2025-02-03T10:23:00.000Z` verificado de ToolAcre, igual a 1,738,578,180 segundos Unix. Para outra época documentada, calcule seu valor usando a origem oficial desse sistema e dimensione com aritmética de números inteiros e, em seguida, converta-o novamente usando a mesma definição.

Compare a viagem de ida e volta com a string Unix ISO e retenha a derivação. Este artigo intencionalmente não preenche uma tabela de cinco épocas com constantes que não foram lidas. O método expõe todas as suposições e pode ser revisado em relação a qualquer protocolo ou formato de arquivo que realmente produziu os dados.

Método trabalhado: derivar um instante entre épocas documentadas em vez de publicar constantes não verificadas

ToolAcre não reconhece nem converte automaticamente épocas estrangeiras. Seu menu de unidade diz segundos e milissegundos, ambos sob a definição Unix na configuração. A detecção automática escolhe apenas entre as escalas de magnitude 10¹¹; nunca muda o ponto zero.

Esse contrato estreito evita a falsa confiança. Se uma contagem estrangeira chegar a uma data Unix plausível, o conversor não poderá avisar que a origem estava errada. A proveniência deve entrar antes da aritmética. Documente a transformação em código em vez de depender de um runbook manual.

O rótulo automático visível informa apenas segundos ou milissegundos. Nunca deve ser citado como evidência de que ocorreu a detecção da origem, porque tal ramificação não existe na fonte.

Conclusão: saiba de qual zero você está contando - e como o conversor de carimbo de data / hora Unix informa claramente que ele lê segundos ou milissegundos Unix

Saiba de qual zero você está contando, qual é o tamanho de um tick e como a fonte lida com sua escala de tempo. Um conversor Unix responde somente depois que essas questões são resolvidas em segundos ou milissegundos desde 1970 UTC. Não pode inferir semântica de um número inteiro.

Use leituras duplas implausíveis como um sinal para investigar a origem, não como permissão para continuar tentando divisores. Depois que uma conversão de origem produz um valor Unix, ToolAcre fornece um UTC útil e independente e uma verificação de integridade local, mantendo sua própria suposição visível.

Um bom adaptador nomeia o tipo estrangeiro, executa uma transformação de origem e emite um valor Unix de marca. Esse design evita que contadores brutos vazem para construtores de data genéricos.