O relógio do Linux falhará em 19 de janeiro de 2038 3:14:08?

Question

Estou um pouco preocupado com isso. É chamado de "problema do ano 2038". O kernel Linux ou Ubuntu está pronto para lidar com datas depois disso ainda, a partir de 12.04?

    

Answer 1

Não, não falhará. Na pior das hipóteses, do ponto de vista de um programador, ele funcionará como esperado: ele será redefinido para data 1901-12-13 20:45:52:

Isso caso você não atualize suas distribuições atuais até que isso aconteça. " A atualização é fácil. Uma dessas atualizações certamente conterá uma correção. " como chocobai disse .

Lembro-me de que era o mesmo problema / questão com máquinas de 16 bits antes de 2000 e, no final, não houve problemas.

Uma solução da Wikipedia:

  

A maioria dos sistemas operacionais projetados para execução em hardware de 64 bits já usa números inteiros assinados de 64 bits time_t . A utilização de um valor de 64 bits assinado introduz uma nova data de abrangência que é 20 vezes maior do que a idade estimada do universo: aproximadamente 292 bilhões de anos a partir de agora, às 15:30:08 de domingo, 4 de dezembro 292.277.026.596. A capacidade de fazer cálculos em datas é limitada pelo fato de que tm_year usa um valor int de 32 bits iniciado a partir de 1900 para o ano. Isso limita o ano a um máximo de 2.147.485.547 (2.147.483.647 + 1900). Embora isso resolva o problema de executar programas, ele não resolve o problema de armazenar valores de data em arquivos de dados binários, muitos dos quais empregam formatos de armazenamento rígidos. Também não resolve o problema para programas de 32 bits executados em camadas de compatibilidade e pode não resolver o problema de programas que armazenam incorretamente valores de tempo em variáveis ​​de tipos diferentes de time_t .

Eu uso o Ubuntu 13.04 em 64 bits e, por curiosidade, mudei manualmente o tempo para 2038-01-19 03:13:00. Depois de 03:14:08 nada aconteceu:

Portanto, não há nada para se preocupar com esse problema.

Mais sobre: ​​

• Problema do ano 2038 - Wikipedia .
• Fim do tempo (Unix) - Numberphile .

Answer 2

Você pode verificar se o tempo do seu computador irá falhar usando o seguinte script Perl:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Se o seu computador vai ficar bem, você vai ter isso:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

Se o seu computador é como o meu, ele ficará assim:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Também poderia fazer isso:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

    

Answer 3

Eu escrevi e publiquei um pequeno artigo sobre isso em 1996. Isso incluiu um pequeno programa em C para demonstrá-lo. Eu também tive e-mails com David Mills sobre problemas semelhantes com o NTP, o Network Time Protocol. No meu laptop Ubuntu 14.04 de 64 bits, o código perl não exibiu a limitação, portanto, as bibliotecas subjacentes de 64 bits devem ter sido modificadas.

No entanto, a execução do meu código de teste há muito tempo mostra a hora de volta ao UNIX Epoch. Portanto, nem tudo está bem com o código de 32 bits do passado.

Meu artigo de 1996, O tempo do UNIX vai acabar em 2038! está no meu site desde por volta de 2000. Uma variante disso intitulada "UNIX Time" foi publicada em 1998 em "Melhores Práticas do Ano 2000 para o Milênio Y2K" ISBN 0136465064.

    

Answer 4

O Linux de 64 bits está pronto, pelo menos se você estiver falando sobre as principais interfaces do sistema operacional (aplicativos individuais podem, é claro, estragar tudo). time_t é tradicionalmente definido como um apelido para "long" e "long" no 64-bit linux é de 64 bits.

A situação para o Linux de 32 bits (e a camada de compatibilidade para binários de 32 bits no Linux de 64 bits) é muito menos otimista. Ele está quebrado e consertá-lo sem quebrar todos os binários existentes não é uma tarefa fácil. Um monte de APIs usa time_t e, em muitos casos, ela é incorporada como parte das estruturas de dados, portanto, as APIs devem ser duplicadas e as estruturas de dados com as quais trabalham também devem ser.

Mesmo se houver algum nível de compatibilidade com versões anteriores, todos os binários que desejarem obter o horário correto precisarão ser recriados para usar as novas interfaces de tempo de 64 bits.

Houve algum trabalho feito (ver, por exemplo, Ссылка e Ссылка ) mas afaict ainda estamos muito longe de uma solução completa. Não está claro se haverá ou não distribuições de 32 bits de propósito geral que sejam seguras para o Y2K38.