Problema do ano 10000
O problema do ano 10000 (também conhecido como Y10K e bug do deca-milênio)[1] é a classe de todos os possíveis erros de formatação e armazenamento de tempo que surgiriam após o surgimento da necessidade de expressar anos com cinco dígitos. O problema pode ter efeitos discerníveis hoje, mas às vezes também é mencionado para fins humorísticos.
Relevância prática editar
Hoje, cinco anos já são um problema para muitos programas de análise prospectiva (por exemplo, software que examina propostas para o manuseio a longo prazo de resíduos nucleares).[carece de fontes]
Exemplos editar
Esse problema pode ser observado no programa de planilha Microsoft Excel, pelo menos, no Office 2013, que armazena datas como o número de dias desde 31 de dezembro de 1899 (o dia 1 é 1900-01-01) com um dia bissexto em 1900; da mesma forma, o Microsoft Access armazena datas como o número de dias desde 30 de dezembro de 1899 (o dia 1 é 1899-12-31). Em qualquer aplicativo, um valor de data de 2958465 será formatado corretamente como "31 de dezembro de 9999", mas adicionar 1 a esse passo para a data prevista de "1 de janeiro de 10000" causará um erro de formatação; no Excel, por exemplo, ele será exibido na célula como uma série de caracteres #. O Excel também não pode converter automaticamente sequências de caracteres no formato de data, como "12/12/2007", em datas se o ano exceder 9999; "12/12/9999" é convertido automaticamente em uma data quando inserido em uma célula, mas "12/12/10000" não. A Fundação Long Now encontrou essa limitação do Excel durante o design do relógio do ano 10000.[2]
O SAP NetWeaver manipula variáveis de data como sequências de oito caracteres (AAAAMMDD).[3]
O programa de código aberto OpenOffice.org Calc é capaz de exibir datas além do ano 9999 corretamente com cinco dígitos, mas pelo menos através da versão 2.4 é vítima do problema do ano 32768: "31 de dezembro de 32767" é a data mais alta disponível corretamente para exibição. 32767 ou 215 – 1, é o número positivo mais alto que pode ser representado usando um número inteiro assinado de 16 bits, adicionando um a esse valor faz com que ele ultrapasse, e o Calc interpreta o ano como um número negativo grande, "de 1 de janeiro de –32768".
O compilador GNU Fortran, g77, faz referência nos limites do ambiente de tempo de execução aos problemas do ano 10000 ao usar funções intrínsecas com este conjunto de compiladores. O problema é simplesmente declarado como "A maioria dos valores intrínsecos que retornam ou calculam valores baseados em informações de data são propensos a problemas do ano 10000 devido ao suporte de apenas quatro dígitos no ano". O modo de falha sugerido em todas as funções intrínsecas é que "os programas que fazem uso dessa intrínseca podem não ser compatíveis com o ano 10000. Por exemplo, a data pode parecer, para esses programas, ser finalizada (mude de um valor maior para um menor) a partir do ano 10000.[4]
O módulo datetime Python suporta explicitamente apenas datas de um a quatro dígitos.[5] Usar uma data que contenha um ano posterior ou anterior resulta em um ValueError sendo gerado.
A classe DateTime PHP pode lidar com anos de cinco dígitos, exceto para analisar cadeias de datas com, por exemplo, new DateTime(...) .
O Microsoft Windows se torna instável quando o ano 10000 é atingido. Após uma reinicialização, a data será redefinida para ~1900 ou algo próximo disso. Isso foi demonstrado por alguns usuários do YouTube.[6][7]
Problemas com representação de dados editar
Diferente do problema do ano 2000, onde dígitos significativos foram omitidos dos valores armazenados de anos, a correção do problema do ano 10000 não exige a atualização de registros antigos (supondo que eles já sejam compatíveis com o Y2K), pois os quatro dígitos significativos estão presentes. Requer apenas que o armazenamento de registros em decimal possa armazenar cinco ou mais dígitos.
Há, no entanto, um problema em potencial com os conjuntos de registros que fazem uso da classificação lexical. Por exemplo, representações de datas no intervalo de 10000 a 19999 apareceriam entrelaçadas com datas no intervalo de 1000 a 1999 em vez de depois do ano de 9999.
Mitigação editar
A Fundação Long Now está tentando promover o costume de escrever anos com cinco dígitos, para que o ano de 2020 seja escrito como "02020". Isso impediria o problema do ano 10000, mas por sua vez seria suscetível ao "problema do ano 100000".
O Internet Kermit Service Daemon (IKSD) usa um campo de cinco dígitos para o ano no formato de registro de banco de dados: "Os campos de data e hora são ajustados à direita em um campo de dezoito com o espaço em branco reservado para Y10K".[8]
A ISO 8601 especifica que os anos sejam escritos com quatro dígitos, mas permite a extensão para cinco ou mais dígitos, com acordo prévio entre as partes que trocam as informações.
Ver também editar
Referências
- ↑ The Long Now Foundation. «About - The Long Now»
- ↑ Roger Smith. «Lessons from the Long Now» (PDF). Software Development Magazine
- ↑ SAP AG. «Predefined ABAP Types»
- ↑ «Year 10000 (Y10K) Problems»
- ↑ «CPython source code for datetime»
- ↑ «Y10K-Bug | A weird experience [Year 10,000 on Windows XP]»
- ↑ «Windows 7 Year 9999 bug»
- ↑ «IKSD – The Internet Kermit Service Daemon». Columbia University
Bibliografia editar
- «The Y10K Problem, Pascal's Wager, and Petersberg». MathPages: Probability and Statistics — O MathPages observa uma semelhança entre o problema do Y10K e a aposta de Pascal e o paradoxo de São Petersburgo, afirmando que o custo de consertar os vários problemas do Y10K, Y100K e sucessivos é aumentado em proporção direta à distância da data, e que, portanto, cada problema deve de fato ter igual peso.
- Brad Templeton. «Computer systems worry over pending "year 10,000" problem» — Templeton coloca a hipótese do impacto do problema do ano 10000.
- Lorin May. «The Year 10,000 Problem: It's Not Too Late to Start»
- «Beyond Year 2000 Compliance: Year 10,000 Compliance». A/P Recap
