Ferramentas para desenvolvedores · Conversor de carimbo de data/hora Unix
O problema do ano 2038: o que acontece quando 32-bit time_t transborda
· Fundo
carimbos de data/hora horário unix depuração
Em 19 janeiro 2038 em 03:14:07 UTC um contador de segundos de 32 bits assinado passa para 1901. Esta postagem explica a aritmética, onde o tempo de 32 bits ainda se esconde e como reconhecer um sistema que será afetado.
Uma data que está mais próxima do que parece: hipotecas, certificados e firmware já computam datas anteriores a 2038
Um limite com data 2038 afeta o código sempre que ele calcula uma expiração, agendamento ou prazo de retenção além desse ponto. A falha pode, portanto, aparecer anos antes da data do relógio. Este repositório não documenta produtos hipotecários, certificados ou firmware, portanto esses exemplos não são apresentados como casos observados.
A questão prática da auditoria é se algum limite armazena segundos Unix em um número inteiro assinado de 32 bits. Um navegador moderno que formata com sucesso uma data futura não diz nada sobre um campo mais restrito a jusante. Rastreie a serialização e a persistência, não apenas a interface do usuário.
Pesquise cálculos de datas futuras em testes hoje, em vez de esperar pelo relógio de produção. Um dispositivo de limite fixo transforma uma preocupação distante do calendário em uma verificação imediata e repetível.
Cálculos de datas futuras podem expor limites de 32 bits antes de 2038, mas os setores nomeados não são evidenciados aqui
O máximo de um inteiro assinado de 32 bits é 2³¹−1 ou 2,147,483,647. Os testes estabelecem tantos segundos após a época como `2038-01-19T03:14:07.000Z`. Mais um segundo matemático deve ser 03:14:08, e ToolAcre o exibe porque JavaScript Número e Data podem carregar o valor.
O agrupamento para um valor negativo requer uma operação externa assinada de 32 bits; `fromEpoch` não executa nenhum. O frequentemente citado resultado 1901 de dezembro pode ser derivado de um wrapper de complemento de dois, mas alegar que cada sistema afetado quebra em vez de rejeitar, saturar ou corromper excederia a evidência. Teste o limite real.
Se uma conversão externa passar pela aritmética de complemento de dois, inspecione os bits armazenados resultantes e o valor negativo decodificado. Não infira o envoltório apenas a partir de uma data histórica inesperada.
O instante superior exato é verificado; o comportamento do wrap depende da operação inteira externa
Pesquise esquemas, definições de protocolo e layouts binários para campos assinados de 32 bits que contêm segundos de época. Uma coluna SQL chamada INTEGER não é evidência suficiente em todos os mecanismos e uma plataforma incorporada não é afetada automaticamente. Determine largura, assinatura, unidade e código de conversão para cada caminho.
Inclua arquivos e registros em cache na auditoria. Um tipo de memória ampliado ainda pode gravar um formato estreito antigo, enquanto um banco de dados amplo pode receber um valor de cliente truncado. Crie fixtures no máximo e um além e, em seguida, inspecione os bytes ou o valor persistido em vez de apenas verificar se uma função retornou com sucesso.
Localize campos de época assinados de 32 bits inspecionando esquemas e formatos reais
A correção conceitual é uma representação cujo intervalo inclui datas exigidas, geralmente uma contagem assinada mais ampla ou um tipo temporal apropriado. A narrativa de migração de kernel, libc e formato da pasta de trabalho está fora desses arquivos de origem. Cada sistema tem seu próprio trabalho de compatibilidade e implantação.
Amplie todas as fronteiras como uma mudança de contrato coordenada. Atualizar o armazenamento sem um campo de ligação ou uma biblioteca sem dados existentes deixa um link estreito. Adicione controle de versão quando necessário e teste leitores antigos explicitamente. A própria definição de época não precisa mudar; o contêiner faz.
O planejamento da migração deve incluir reversão e comportamento de versão mista. Um novo gravador que produz valores amplos pode interromper um leitor antigo antes que qualquer data persistente atinja o limite do calendário.
Ampliar a representação é a solução principal; migrações de kernel e formato são específicas do sistema
Converta 2,147,483,647 em segundos para obter `2038-01-19T03:14:07.000Z`; converta 2,147,483,648 para obter `2038-01-19T03:14:08.000Z`. A etapa suave de um segundo prova que o caminho ToolAcre não tem nenhum penhasco de 32 bits nesse valor.
Agora force os mesmos números dos milissegundos. Eles caem em janeiro 1970 porque os valores ficam aproximadamente vinte e cinco dias depois de zero. Essa comparação evita que um erro de unidade seja rotulado erroneamente como um problema 2038. A largura e a escala do campo são dimensões independentes.
Esta comparação também demonstra por que um conversor é diagnóstico e não vulnerável: a seleção explícita da unidade determina a escala, enquanto a representação mais ampla do navegador carrega ambos os valores.
Exemplo resolvido: o conversor cruza o limite porque JavaScript A data não está assinada 32 bits segundos
O repositório também testa 4,294,967,295 segundos como `2106-02-07T06:28:15.000Z`, a contagem máxima de 32 bits não assinados. Ele não testa um rollover de GPS semanas nem especifica um penhasco assinado de 64 milissegundos de bits, portanto, esses tópicos nomeados são omitidos em vez de generalizados.
A análise de limites deve seguir o tipo exato em uso. Mudar de assinado para não assinado estende uma direção, mas remove datas negativas e ainda cria uma borda superior. Uma representação assinada mais ampla geralmente preserva ambas as direções, sujeita ao intervalo de datas do consumidor.
Cada penhasco precisa de sua própria derivação de largura, sinalização e unidade. O agrupamento de rollovers não relacionados em “2038” obscurece qual campo binário realmente requer alteração.
O limite não assinado de 32 bits é testado; outros penhascos nomeados estão fora das evidências do repositório
Um conversor não pode auditar código-fonte, binários, esquemas de banco de dados ou dispositivos implantados. Ele mostra o que significa um número de candidato e fornece acessórios concretos para testes. A pesquisa estática, a inspeção de tipo, os testes de serialização e o ensaio de migração devem estabelecer se um produto é seguro.
Não feche uma auditoria porque o navegador renderiza 2038 corretamente. Isso apenas verifica o caminho do navegador. Siga o valor de ponta a ponta, especialmente por meio de ligações de linguagem e formatos antigos onde pode ocorrer estreitamento implícito.
Inclua interfaces de dependência e de fornecedor nesse rastreamento. A origem do aplicativo pode usar um tipo amplo, enquanto uma biblioteca nativa ou protocolo de dispositivo restringe o mesmo valor de forma invisível.
Conclusão: a época está boa, a largura inteira é o problema - e como o conversor de carimbo de data / hora Unix permite verificar qualquer valor limite em UTC e na hora local
O problema do ano 2038 é um limite de largura inteira, não um defeito na aritmética da época do Unix. A conversão bem-sucedida de ToolAcre em ambos os lados torna essa separação visível. O sistema externo falha apenas se uma de suas representações não puder realizar a próxima contagem.
Use 2,147,483,647 e 2,147,483,648 como vetores de teste adjacentes, verifique a persistência exata e documente a unidade e a assinatura. As evidências em todas as fronteiras são mais valiosas do que uma lista de verificação genérica de tecnologias supostamente vulneráveis.
Os vetores adjacentes devem cruzar um caminho de serialização real, não apenas um cálculo na memória. É aí que uma aplicação nominalmente alargada pode revelar uma costura estreita remanescente.