Um relógio que na verdade é um único número
Quase todos os aparelhos em que tocou hoje concordam num número. Não na hora da sua cidade, nem no seu calendário, nem no seu fuso: um único número inteiro que conta os segundos passados desde a meia-noite de 1 de janeiro de 1970 em UTC. Esse número chama-se tempo Unix e, neste momento, é um número de dez dígitos que aumenta um a cada segundo.
É uma ideia elegante. Em vez de guardar “terça-feira, 15 horas em Lisboa”, com todas as suas regras humanas, uma máquina guarda algo como 1771200000. Um instante, um número, sem ambiguidade. O seu servidor em Frankfurt, o seu telemóvel em São Paulo e um sensor numa fábrica concordam nele, mesmo que os relógios de parede mostrem coisas diferentes. Pode ver o número atual e traduzi-lo numa data legível no nosso conversor de timestamp Unix.
O problema é que um número que só sobe acaba por ficar sem espaço. E para uma forma muito concreta e muito comum de guardar o tempo Unix, sabemos exatamente quando: às 03:14:07 UTC de 19 de janeiro de 2038.
Porquê 1970
O ponto de partida, chamado “época” (epoch), é 1 de janeiro de 1970. Não há nada de cósmico nisso. No início dos anos 1970, os engenheiros que construíam o Unix nos Bell Labs precisavam de uma data zero prática e recente, e um começo redondo de década servia perfeitamente. Os instantes anteriores a 1970 são simplesmente representados por números negativos.
Essa decisão modesta espalhou-se por todo o mundo digital. Hoje o tempo Unix está dentro de bases de dados, protocolos de rede, sistemas de ficheiros, registos e firmware de aparelhos que os seus criadores nunca imaginaram. A data de origem quase nunca importa. O que importa é quanto espaço o computador reservou para guardar o número.
O número que se esgota
Durante décadas, a forma habitual de guardar o tempo Unix foi um inteiro de 32 bits com sinal. “Com sinal” quer dizer que um bit serve para distinguir números positivos de negativos, o que deixa um valor máximo de 2.147.483.647. É essa a quantidade de segundos que esse contador consegue alojar.
Some 2.147.483.647 segundos à meia-noite de 1970 e chega às 03:14:07 UTC de terça-feira, 19 de janeiro de 2038. Um segundo depois, o contador transborda. Como o bit de sinal muda, o número não salta para 2.147.483.648: torna-se negativo e aterra em 13 de dezembro de 1901. Imagine o conta-quilómetros de um carro antigo a passar de 999999 para 000000, só que aqui o carro aparece de repente no século anterior.
Há um detalhe que encanta os entusiastas: a hora limite é 03:14:07, ou seja 3, 14, 7, uma piscadela aos primeiros dígitos de pi. O tempo Unix tem vários destes momentos celebrados, e o de 2038 é simplesmente o primeiro que parte coisas em vez de enfeitar uma t-shirt.
| Valor de tempo Unix | Momento (UTC) | Porque se recorda |
|---|---|---|
| 0 | 1 de janeiro de 1970, 00:00:00 | A época: o segundo zero do qual tudo depende. |
| 1.000.000.000 | 9 de setembro de 2001, 01:46:40 | O “Unix billennium”, celebrado por programadores. |
| 1.234.567.890 | 13 de fevereiro de 2009, 23:31:30 | Uma contagem com dígitos ordenados; houve festas a sério. |
| 2.147.483.647 | 19 de janeiro de 2038, 03:14:07 | O teto dos 32 bits com sinal: o problema do ano 2038. |
Porque não é o bug do ano 2000 com outra roupagem
É tentador arquivar isto ao lado do bug do ano 2000 (Y2K) e seguir em frente. Mas são problemas diferentes. O bug do ano 2000 era uma convenção humana: o software guardava os anos com dois dígitos, por isso “99” passava a “00” e o computador não sabia se era 1900 ou 2000. Era um problema de formato, sobretudo na camada onde as pessoas leem e escrevem datas.
O ano 2038 é mais profundo. Não se trata de como uma data é mostrada, mas da unidade fundamental com que a máquina conta o tempo. Não se corrige escrevendo anos com quatro dígitos no ecrã; é preciso aumentar o próprio recipiente que guarda o número.
| Ano 2000 | Ano 2038 | |
|---|---|---|
| Raiz do problema | Anos guardados com dois dígitos | Segundos guardados em 32 bits com sinal |
| Camada afetada | Formato e apresentação | O tipo de dados e o armazenamento subjacente |
| Solução típica | Usar anos de quatro dígitos | Usar inteiros de 64 bits para o tempo |
| Mais difícil de mudar | Lógica da aplicação | Formatos em disco, protocolos e aparelhos antigos |
O mais curioso: 2038 já está a partir coisas
O erro subtil é pensar que é um precipício distante. Não é. Qualquer sistema que calcule datas para o futuro já cruza a fronteira de 2038 hoje. Um crédito a trinta anos assinado em 2026 calcula vencimentos posteriores a 2038. Um certificado, uma garantia, uma apólice ou uma subscrição de longa duração fazem aritmética que ultrapassa o limite muito antes de a data chegar.
Por isso já houve falhas isoladas: um sistema que tenta representar “daqui a vinte anos” num inteiro de 32 bits obtém de repente uma data de 1901, um prazo negativo ou um erro inexplicável. O ano 2038 não espera por 2038. Chega mais cedo a qualquer código que olhe suficientemente longe para a frente.
Onde dói mesmo, e onde não
A boa notícia é que o seu portátil e o seu telemóvel estão quase de certeza a salvo. Os sistemas operativos modernos de 64 bits já guardam o tempo Unix em inteiros de 64 bits. O JavaScript conta o tempo em milissegundos dentro de um número de vírgula flutuante que não tem problemas senão daqui a centenas de milhares de anos. O Python usa inteiros de precisão ilimitada. Para a maioria do software atualizado, 2038 é uma nota de rodapé.
O perigo vive noutro lado: em aparelhos de 32 bits com vidas longas e atualizações raras. Routers, controladores industriais, contadores inteligentes, equipamento médico, centralinas de automóvel e sensores que se instalam e esquecem durante vinte ou trinta anos. E também nos formatos: campos de data fixos de 32 bits dentro de ficheiros, protocolos de rede, sistemas de ficheiros antigos e colunas de bases de dados desenhadas há muito tempo. O processador pode estar pronto, mas os dados guardados no formato antigo não se corrigem sozinhos.
A correção é aborrecida, e ainda bem
A solução principal é simples de descrever: guardar o tempo num inteiro de 64 bits com sinal em vez de 32. Isso alarga o alcance do contador para cerca de 292 mil milhões de anos, muito além da idade do universo. Não é preciso inventar nada de novo; basta dar mais espaço ao número.
Grande parte desse trabalho já está feita. O núcleo do Linux dedicou anos a tornar seguras face a 2038 mesmo as plataformas de 32 bits, as bibliotecas padrão foram atualizadas e os BSD fizeram o mesmo. A parte difícil não são os processadores, mas os dados em repouso: migrar formatos de ficheiro, protocolos e aparelhos antigos sem partir tudo o que já depende deles. É trabalho silencioso, pouco glamoroso e profundamente útil; exatamente como deve ser uma boa engenharia de infraestrutura.
O que pode fazer
- Verifique se a sua linguagem ou base de dados guarda o tempo em 32 ou 64 bits, sobretudo em sistemas antigos.
- Procure qualquer sítio onde calcule datas a anos ou décadas de distância; esse código cruza 2038 hoje.
- Reveja os aparelhos embebidos e o firmware com vidas longas, onde as atualizações são raras.
- Trate as datas em disco e nos protocolos como contratos: mudar o tamanho de um campo de tempo afeta tudo o que o lê.
- Teste o relógio do sistema para além de 2038 num ambiente controlado para ver o que parte antes de importar.
Um número que vale a pena vigiar
O problema do ano 2038 é um bom lembrete de que o tempo digital é uma escolha humana, não uma lei natural. Decidimos contar segundos, decidimos começar em 1970 e decidimos quantos bits lhe dedicar. Cada uma dessas decisões era razoável quando foi tomada, e cada uma deixa uma marca que dura décadas.
Entretanto, o contador continua a subir em silêncio, um segundo por segundo. Se tem curiosidade em vê-lo, veja o número atual no nosso conversor de timestamp Unix, confirme a data de hoje ou calcule quanto falta para uma data futura com a calculadora de prazos. E se lhe interessam os erros de tempo que já partem software hoje, o nosso guia sobre os bugs de data e hora mais comuns continua a história.