ti-enxame.com

Problema do ano 2038

Qual é a probabilidade de o problema do ano de 2038 ser muito problemático?

28
8128

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

Embora a maioria dos sistemas deva estar pronta bem antes de 2038, se você hoje calcula datas em um futuro distante, pode ter um problema.

17
Alex B

Há alguns anos, já havia relatos de problemas em áreas como programas de hipotecas que fazem cálculos sobre empréstimos de 30 anos: 2008 + 30 = 2038.

9
Warren Young

Esta é minha opinião, mas este problema é devido a um problema de contador de 32 bits, hoje a maioria dos sistemas operacionais são atualizados para lidar com o tempo em 64 bits (pelo menos em computadores de 64 bits), então eu acho que todos os sistemas operacionais e softwares estarão prontos por muito tempo antes de 2038, digamos 2020. Portanto, você só poderá ter problemas se em 2038 ainda estiver executando o software de 2020.
Provavelmente não será um problema em quase todos os casos. Eu espero.

8
radius

Um sistema operacional de 64 bits é irrelevante para o problema de 2037. (CTIME termina mais perto 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 o tempo. Ou como esse atributo da sintaxe de tempo dos serviços de diretório armazena o tempo no backend.

Este é um problema muito maior do que as pessoas pensam, uma vez que é tão endêmico e comum usar contadores de tempo de 32 bits.

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

Camadas de abstração que permitem definir a hora por meio de um formato de hora legível por humanos, em vez dos dados brutos gravados tornam isso mais fácil, mas esse é apenas um caso.

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

8
geoffc

Não é grande coisa.

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

Na época, como o custo do teste era tão alto, eles quase sempre testavam com várias datas, como 1/1/99 (alguns desenvolvedores podem ter usado 99 como sentinal), 31/12/99, 1/1/00, o salto de 2000, 19/01/38 e muitos outros. Veja aqui para uma lista tediosa.

Portanto, acredito que qualquer software importante que existia em 1999 provavelmente não teria 2038 bugs, mas um novo software escrito desde então por programadores ignorantes pode ter. Depois de todo o desastre do Y2K, os programadores geralmente ficaram muito mais cientes dos problemas de codificação de data, então é improvável que tenha um impacto tão grande quanto o Y2K (o que, por si só, foi uma espécie de anticlímax).

1
Joel Spolsky

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

1
user55149
#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));
}

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

8 - Sun Jun 13 07:26:08 1141709097

O tempo do meu sistema (64 bits, é claro) pode durar até mais 1 milhão de anos. 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:

  • int são 32 bits (na verdade, eles são preservados como 32 bits em sistemas de 64 bits, entre outros, porque foi assumido que eles são sempre de 32 bits)
  • A maioria dos tipos (como time_t) pode ser lançado com segurança em int

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

Eu acho que no mundo livre * nix o 2038 ficará 'despercebido' enquanto eu espero problemas em plataformas "proprietárias" (ou seja, aquelas com grande número de software proprietário) - especialmente se alguma parte crucial não for mantida.

0
Maciej Piechotka

Se for algo como o Y2K, algumas pessoas já foram afetadas e estão mudando o software, mas a maioria dos desenvolvedores irá ignorar até em algum momento da década de 2030, provavelmente 2035 ou assim, quando haverá muito trabalho realizado e qualquer pessoa com idade suficiente conhecer K&R C e ainda não ser muito senil poderá, de repente, fazer um contrato por muito dinheiro. A transição real mostrará muitas coisas que ainda não foram feitas, provavelmente nenhuma tão importante.

0
David Thornley