Qual é a probabilidade de a edição do ano 2038 ser muito problemática?
Eu encontrei este problema em um sistema Linux embarcado que precisava lidar com datas anteriores a 2038 em alguns certificados criptográficos de longo prazo, portanto, eu diria que a conveniência disso depende do seu domínio de aplicativo.
Enquanto a maioria dos sistemas deve estar pronta bem antes de 2038, se você se encontrar hoje calculando datas no futuro, você pode ter um problema.
Eu acho que isso vai ser um problema significativo, muito mais pernicioso do que os problemas do ano 2000, porque o código afetado é geralmente de nível mais baixo (é CTIME) e por isso é mais difícil identificar lugares onde o tempo está sendo armazenado dessa maneira.
Para complicar ainda mais as coisas, o fato de o Y2K ter sido percebido como um squib úmido tornará mais difícil chamar a atenção para o problema na corrida para o evento.
Referências culturais:
Cory Doctorow estava experimentando um novo modelo de comissionamento de contos / publicando sob licenças abertas, e eu sugeri um tema de 2038 de um deles, o que ele fez brilhantemente na Epoch: link
Há alguns anos, já havia relatos de problemas, em áreas como programas hipotecários fazendo cálculos em empréstimos de 30 anos: 2008 + 30 = 2038.
Um sistema operacional de 64 bits é irrelevante para o problema de 2037. (CTIME sai mais perto de 2037 do que 2038).
A questão não é a profundidade de bits do sistema operacional, e sim como o tempo de armazenamento do sistema operacional. Ou como a coluna do banco de dados escolhe armazenar tempo? Ou como esse tempo de armazenamento de atributo de sintaxe de tempo de serviços de diretório no back-end.
Este é um problema muito maior do que as pessoas pensam, já que é tão endêmico e comum ter usado contadores de tempo de 32 bits.
Cada instância que armazena tempo precisa ser revisitada, e todas as APIs atualizadas e todas as ferramentas que a usam também são atualizadas.
Camadas de abstração que permitem definir o tempo por meio de um formato de hora legível por humanos, em vez de os dados brutos gravados ficarem mais fáceis, mas esse é apenas um caso.
Eu suspeito que este será um negócio muito maior do que a maioria das pessoas pensa.
Esta é a minha opinião, mas este problema é devido a um problema de contador de 32 bits, hoje a maioria dos SO é atualizada para manipular o tempo em 64 bits (pelo menos em computadores de 64 bits), então acho que todos os SO e software serão pronto um longo tempo antes de 2038, digamos que 2020. Então você só pode ter problemas se em 2038 você ainda estará executando o software a partir de 2020.
Provavelmente não será um problema em quase todos os casos. Eu espero.
Durante a primeira blitz do Y2K, em que os fornecedores de software e hardware precisavam certificar seus produtos como "compatíveis com Y2K" para serem vendidos (lembro-me de cabos de rede compatíveis com o Y2K) muitas empresas detalharam auditorias de tudo, configurando relógios no futuro e testando.
Na época, como o custo do teste era tão alto, eles quase sempre eram testados com várias datas, como 1/1/99 (alguns desenvolvedores podem ter usado 99 como sentinela), 31/12/99, 1 / 1/00, o salto de 2000, 19/1/38 e muitos outros. Veja aqui para uma lista tediosa.
Assim, acredito que qualquer software importante que existisse em 1999 provavelmente não teria 2038 bugs, mas novos softwares escritos desde então por programadores ignorantes poderiam. Depois de todos os programadores debacle do Y2K terem se tornado muito mais conscientes dos problemas de codificação de datas, é improvável que isso tenha um impacto tão grande quanto o Y2K (que, por si só, era um pouco anticlímax).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 ctime não processa data maior:
8 - Sun Jun 13 07:26:08 1141709097
O tempo do meu sistema (64 bits, é claro) pode chegar a 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, propertário e não mantido. Os desenvolvedores estão acostumados a seguir 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) time_t ) pode ser convertida com segurança em int
No popular software FLOSS, ambas as coisas provavelmente não passarão pela revisão 'muitos olhos'. Em menos popular e propri- tário, dependerá largamente do autor.
Eu acho que no mundo livre * nix o 2038 vai ficar 'despercebido' enquanto eu espero problemas em plataformas "proprietárias" (ou seja, aquelas com grande número de software proprietário) - especialmente se parte da parte não for mantida.
Se é algo parecido com o Y2K, algumas pessoas já foram afetadas e estão mudando de software, mas a maioria dos desenvolvedores irá ignorá-lo até a década de 2030, provavelmente em 2035, e nesse ponto haverá muito trabalho feito, e qualquer pessoa com idade suficiente para conhecer K & RC e ainda não muito senil, poderá subcontratar-se por muito dinheiro. A transição real mostrará muitas coisas ainda não feitas, provavelmente nenhuma tão importante.
O problema do Y2K foi de duas cartas representando o ano em vez de quatro.
Muitos sistemas não tinham como distinguir entre 2000 e 1900, já que eles apenas armazenavam o '00'.
Quase todo o sistema agora usa 4 caracteres para armazenar o ano ou usa uma biblioteca de algum tipo.
Então, vamos nos preocupar com o ano 10000 (Y10K). Exceto pelos escritores do SO e da Biblioteca ...
Tags date