Eu marquei isso como um wiki da comunidade, então fique à vontade para editar quando quiser.
Qual é exatamente o problema do ano de 2038?
"O problema do ano 2038 (também conhecido como Unix Millennium Bug, Y2K38 por analogia com o problema Y2K) pode fazer com que alguns softwares de computador falhem antes ou no ano 2038. O problema afeta todos os softwares e sistemas que armazenam a hora do sistema como um 32 assinado -bit inteiro e interprete esse número como o número de segundos desde 00:00:00 UTC em 1º de janeiro de 1970."
Por que ocorre e o que acontece quando ocorre?
Horários além de 03:14:07 UTC na terça-feira, 19 de janeiro de 2038 será 'envolvido' e armazenado internamente como um número negativo, que esses sistemas interpretarão como uma hora em 13 de dezembro de 1901 em vez de 2038. Isso se deve ao fato de que o número de segundos desde a época do UNIX (1 de janeiro 1970 00:00:00 GMT) terá excedido o valor máximo de um computador para um inteiro com sinal de 32 bits.
Como podemos resolver isso?
- Use tipos de dados longos (64 bits são suficientes)
- Para MySQL (ou MariaDB), se você não precisar das informações de tempo, considere usar o
DATEtipo de coluna. Se você precisar de maior precisão, useDATETIMEem vez deTIMESTAMP. Esteja ciente de queDATETIMEas colunas não armazenam informações sobre o fuso horário, portanto, seu aplicativo precisará saber qual fuso horário foi usado. - Outras soluções possíveis descritas na Wikipedia
- Aguarde que os desenvolvedores do MySQL corrijam este bug relatado há mais de uma década.
Existem alternativas possíveis para usá-lo que não representem um problema semelhante?
Tente sempre que possível usar tipos grandes para armazenar datas em bancos de dados:64 bits é suficiente - um tipo longo em GNU C e POSIX/SuS, ou
sprintf('%u'...) em PHP ou na extensão BCmath. Quais são alguns casos de uso potencialmente importantes, embora ainda não estejamos em 2038?
Portanto, um MySQL DATETIME tem um intervalo de 1000-9999, mas TIMESTAMP tem apenas um intervalo de 1970-2038. Se o seu sistema armazena datas de nascimento, datas futuras (por exemplo, hipotecas de 30 anos) ou similares, você já encontrará esse bug. Novamente, não use TIMESTAMP se isso for um problema.
O que podemos fazer com os aplicativos existentes que usam TIMESTAMP, para evitar o chamado problema, quando ele realmente ocorre?
Poucos aplicativos PHP ainda existirão em 2038, embora seja difícil prever, já que a web ainda não é uma plataforma herdada.
Aqui está um processo para alterar uma coluna da tabela de banco de dados para converter
TIMESTAMP para DATETIME . Começa com a criação de uma coluna temporária:# rename the old TIMESTAMP field
ALTER TABLE `myTable` CHANGE `myTimestamp` `temp_myTimestamp` int(11) NOT NULL;
# create a new DATETIME column of the same name as your old column
ALTER TABLE `myTable` ADD `myTimestamp` DATETIME NOT NULL;
# update all rows by populating your new DATETIME field
UPDATE `myTable` SET `myTimestamp` = FROM_UNIXTIME(temp_myTimestamp);
# remove the temporary column
ALTER TABLE `myTable` DROP `temp_myTimestamp`
Recursos
