O problema do ano 2038: o limite dos timestamps Unix
O tempo não para. Uma forma específica de o guardar atinge o maior número positivo.
Um contador com espaço limitado
O tempo Unix conta segundos desde 1 de janeiro de 1970 às 00:00:00 UTC, sem contar segundos intercalares. Um inteiro de 32 bits com sinal chega a 2 147 483 647. Em segundos Unix, corresponde a 19 de janeiro de 2038 às 03:14:07 UTC. Um segundo depois, o valor já não cabe nessa representação. A data é normal; o problema é o limite de armazenamento.
Nem todos os computadores têm esse limite
O problema afeta sistemas, formatos, protocolos ou bases de dados que ainda usam essa representação limitada. Tipos mais largos permitem datas posteriores. Uma aplicação moderna pode trocar dados com um componente antigo, pelo que observar o relógio não basta. Um valor fora do intervalo pode ser rejeitado, truncado ou mal interpretado. Não é correto dizer que todos os dispositivos regressarão a 1901 ou que a Internet vai parar.
Outra armadilha é mil vezes menor
Segundos e milissegundos são unidades diferentes. Introduza 2 147 483 647 como milissegundos e chegará a janeiro de 1970, não de 2038. Adivinhar a unidade pelo número de algarismos é pouco fiável, sobretudo com datas antigas ou valores pequenos. A nossa ferramenta pede a unidade explicitamente. Ao depurar, anote valor, unidade e resultado UTC esperado. Esse hábito evita muitos erros de data.
Explore o limite
Experimente 2147483647 e 2147483648 com segundos selecionados. Os resultados devem diferir por um segundo, ambos em 2038, porque esta ferramenta não está limitada a segundos Unix de 32 bits com sinal. Isso demonstra este cálculo, não a preparação de todos os seus sistemas. Para avaliar uma aplicação, teste armazenamento e interfaces com datas dos dois lados, guardando e relendo os valores. A apresentação correta é apenas uma parte.
Teste a sua intuição
Fontes e leituras
Explicações originais com exemplos resolvidos. As referências apontam para as normas e documentação de base.