Proponha uma correção, faça uma sugestão
Conhece problema do ano 2038? É considerado o bug do milénio
O problema do ano 2000 é conhecido pela maioria das pessoas atualmente devido à grande quantidade de atenção que recebeu por parte dos meios de comunicação social. A maioria dos programas escritos em C são relativamente imunes ao problema do Y2K, mas sofrem com o problema do ano 2038. Mas o que implica esse problema?
Este problema surge porque a maioria dos programas em C usa uma biblioteca de rotinas chamada biblioteca de tempo padrão (standard time library: <time.h>). Esta biblioteca estabelece um formato padrão de 4 bytes para o armazenamento de valores de tempo, e também fornece uma série de funções para converter, exibir e calcular valores de tempo.
O formato padrão de 4 bytes assume que o início do tempo é 1 de janeiro de 1970, à 00:00:00. Este valor é zero. Qualquer valor de hora/data é expresso como o número de segundos a seguir a esse valor zero. Assim, o valor 919642718 é 919.642.718 segundos após a 00:00:00 de 1 de janeiro de 1970, que é Domingo, 21 de fevereiro de 1999, às 23:18:38 GMT.
Este é um formato conveniente porque se subtrair dois valores quaisquer, obtém um número de segundos que é a diferença de tempo entre eles. Depois, pode utilizar outras funções da biblioteca para determinar quantos minutos/horas/dias/meses/anos passaram entre as duas horas.
Mas qual é o problema do ano 2038?
Um número inteiro de 4 bytes com sinal tem um valor máximo de 2.147.483.647, e é daí que vem o problema do ano 2038. O valor máximo do tempo antes de passar para um valor negativo (e inválido) é 2.147.483.647, o que se traduz em 19 de janeiro de 2038. Nesta data, qualquer programa em C que use a biblioteca de tempo padrão começará a ter problemas com cálculos de data.
Felizmente, este problema é um pouco mais fácil de resolver do que o problema do Y2K nos mainframes. Programas bem escritos podem simplesmente ser recompilados com uma nova versão da biblioteca que usa, por exemplo, valores de 8 bytes para o formato de armazenamento.
Isto é possível porque a biblioteca encapsula toda a atividade temporal com os seus próprios tipos e funções de tempo (ao contrário da maioria dos programas de mainframe, que não padronizaram os seus formatos de data ou cálculos). Assim, o problema do ano 2038 não deve ser tão difícil de resolver como foi o problema do Y2K.
Leia também:
Loading ...
Ó ome, antes disso ainda vem mais uma pandemia e uma guerra nuclear híbrida e talvez os aliens.
Ahahah um dos melhores comentários 😀
Relativamente à guerra não sei mas que sei que o Inverno Nuclear se aproxima a passos largos 🙁
Só mais uma? Tas tolo. Vai começar uma nova já no final deste ano.
Os alliens 1 , sei de fonte segura lol
E isto afeta MySQL quem utilizar uma coluna com tipo timestamp.
VAMOS TODOS MORRERRRRRRRRRRRRRRRR!!!!!!!!!
De quê não sei, mas certamente por causa deste “bug” não é. Temos 14 anos para resolver. Logo, a UE vai reunir, estudar, fazer análises, contratar peritos, legislar, ratificar… e quando chegarmos a 2028 ainda não sabem o que fazer 😀
Também ia haver um bug do milénio em 2000, o tanas.
Não ia haver, havia e foi corrigido atempadamente!
Tal como este também será, como todos os bugs de software que se descobrem e são sempre resolvidos, caso haja necessidade.
? tiveste pessoas a ter a luz e agua cortada noutros países porque não pagavam a luz há 100 anos, tiveste alunos a ser expulsos de escolas e universidades porque estavam lá há demasiado tempo, a rainha da Inglaterra mandou cartões a felicitar recém nascidos por fazerem 100 anos, tiveste sistemas bancários que estiveram indisponíveis durante dias.
Em 2038 o mundo vai tar todo ao contrário. Até vai dar parar rir falar sobre este problema 🙂