Problema no ano 2038 [fechado]

Qual é a probabilidade da edição do ano 2038 ser muito problemática?

Eu encontrei esse problema em um sistema Linux incorporado que precisava lidar com datas anteriores a 2038 em alguns certificados criptográficos de longo prazo, então eu diria que a similaridade disso depende do domínio do seu aplicativo.

Embora a maioria dos sistemas deva estar pronta bem antes de 2038, se você se encontra hoje calculando datas para o futuro, pode ter um problema.

Penso que este será um problema significativo, muito mais pernicioso do que os problemas do ano 2000/2000, porque o código afetado é geralmente de nível inferior (é CTIME) e, portanto, é mais difícil identificar locais onde o tempo está sendo armazenado dessa maneira.

Para complicar ainda mais as coisas, o fato de o Y2K ser considerado um bebê úmido tornará mais difícil chamar a atenção para o problema no período que antecede o evento.

Referências culturais:

Cory Doctorow estava experimentando um novo modelo para o comissionamento / publicação de histórias curtas sob licenças abertas, e eu sugeri um tema para 2038 para um deles, o que ele fez brilhantemente na época: http://craphound.com/?p=2337

Alguns anos atrás, já havia relatos de problemas, em áreas como programas de hipotecas que calculavam empréstimos de 30 anos: 2008 + 30 = 2038.

Um sistema operacional de 64 bits é irrelevante para o problema de 2037. (O CTIME termina mais próximo de 2037 do que 2038).

A questão não é a profundidade de bits do sistema operacional, mas como o sistema operacional armazena o tempo. Ou como a coluna do banco de dados escolhe armazenar tempo. Ou como esse atributo de sintaxe de tempo dos serviços de diretório armazena o tempo no backend.

Esse é um problema muito maior do que as pessoas pensam, pois é muito endêmico e comum o uso de contadores de tempo de 32 bits.

Cada instância que armazena tempo precisa ser revisada, e todas as APIs atualizadas e todas as ferramentas que a utilizam também são atualizadas.

As camadas de abstração que permitem definir a hora através de um formato de hora legível por humanos, em vez dos dados brutos gravados, facilitam, mas esse é apenas um caso.

Eu suspeito que isso vai ser um negócio muito maior do que a maioria das pessoas pensa.

Esta é minha opinião, mas esse problema é devido a um problema de contador de 32 bits, hoje a maioria dos sistemas operacionais é atualizada para lidar com o tempo em 64 bits (pelo menos em computadores de 64 bits), então acho que todo o SO e software estará pronto por muito tempo. antes de 2038, digamos 2020. Portanto, você poderá ter problemas apenas se, em 2038, continuar executando o software a partir de 2020.
Provavelmente não será um problema em quase todos os casos. Eu espero.

Não é grande coisa.

Durante a primeira blitz Y2K, na qual os fornecedores de software e hardware eram obrigados a certificar seus produtos como "compatíveis com Y2K" para serem vendidos (lembro-me de que os cabos de rede no PC Connection eram certificados como compatíveis com Y2K) muitas empresas fizeram auditorias detalhadas de tudo , definindo relógios no futuro e testando.

Na época, como o custo dos testes era muito alto, eles quase sempre eram testados com várias datas, como 1/1/99 (alguns desenvolvedores podem ter usado 99 como sentinal), 31/12/99, 1/1 / 1 / 00, o salto de 2000, 19/1/38, e muitos outros. Veja aqui uma lista tediosa.

Portanto, acredito que qualquer software importante que existia em 1999 provavelmente não terá 2038 erros, mas um novo software escrito desde então por programadores ignorantes. Depois que todo o programa de debacle do Y2K geralmente ficou muito mais ciente dos problemas de codificação de datas, é improvável que tenha um impacto tão grande quanto o Y2K (o que, por si só, era um anticlímax).

Os sistemas de 32 bits ainda em execução até então serão um problema.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

deve ser 1 em vez de 9, mas o ctime não lida com datas maiores:

8 - Sun Jun 13 07:26:08 1141709097

O tempo do meu sistema (64 bits, é claro) pode demorar até 1 milhão de anos a mais. A solução é atualizar os sistemas para 64 bits.

O problema é que os programas podem não lidar com isso. Especialmente antigo, proprietário e não mantido. Os desenvolvedores estão acostumados aos seguintes fatos:

• intsão 32 bits (na verdade, eles são preservados como 32 bits em sistemas de 64 bits, entre outros porque se supunha que eles sempre fossem 32 bits)
• A maioria dos tipos (como time_t) pode ser transmitida com segurança emint

No popular software FLOSS, ambas as coisas provavelmente não passarão pela revisão de 'muitos olhos'. Em menos popular e apropriado, dependerá amplamente do autor.

Eu acho que no mundo free * nix o 2038 passará despercebido enquanto espero problemas em plataformas "proprietárias" (ou seja, aquelas com grande número de softwares proprietários) - especialmente se parte da parte essencial não for mantida.

Se é algo como o Y2K, algumas pessoas já foram afetadas e estão mudando o software, mas a maioria dos desenvolvedores o ignorará até algum momento da década de 2030, provavelmente 2035, quando então haverá muito trabalho e alguém com idade suficiente. conhecer a K&R C e ainda não muito senil poderá repentinamente contratar muito dinheiro. A transição real mostrará muitas coisas ainda não feitas, provavelmente nenhuma tão importante.

O problema do ano 2000 era de duas cartas representando o ano em vez de quatro.

Muitos sistemas não tinham como distinguir entre 2000 e 1900, pois apenas armazenavam o '00'.

Quase todos os sistemas agora usam 4 caracteres para armazenar o ano ou usam algum tipo de biblioteca.

Então, vamos todos se preocupar com o ano 10000 (Y10K). Exceto pelos escritores do SO e da Biblioteca ...