O que devemos fazer para nos preparar para 2038?

Question

Eu gostaria de pensar que alguns dos softwares que estou escrevendo hoje serão usados ​​em 30 anos.Mas também estou ciente de que muito disso se baseia na tradição do UNIX de expor o tempo como o número de segundos desde 1970.

#include <stdio.h>
#include <time.h>
#include <limits.h>

void print(time_t rt) {
    struct tm * t = gmtime(&rt);
    puts(asctime(t));
}

int main() {
    print(0);
    print(time(0));
    print(LONG_MAX);
    print(LONG_MAX+1);
}

A execução resulta em:

• Qui, 1º de janeiro 00:00:00 1970
• Sábado, 30 de agosto 18:37:08 2008
• Terça, 19 de janeiro 03:14:07 2038
• Sexta-feira, 13 de dezembro 20:45:52 1901

As funções ctime(), gmtime() e localtime() tomam como argumento um valor de tempo que representa o tempo em segundos desde a Época (00:00:00 UTC, 1º de janeiro de 1970;veja tempo(3) ).

Eu me pergunto se há algo proativo a ser feito nesta área como programador, ou devemos confiar que todos os sistemas de software (também conhecidos como sistemas operacionais) serão de alguma forma atualizados magicamente no futuro?

Atualizar Parece que de fato os sistemas de 64 bits estão protegidos disso:

import java.util.*;

class TimeTest {
    public static void main(String[] args) {
        print(0);
        print(System.currentTimeMillis());
        print(Long.MAX_VALUE);
        print(Long.MAX_VALUE + 1);
    }

    static void print(long l) {
        System.out.println(new Date(l));
    }
}

• Quarta, 31 de dezembro 16:00:00 PST 1969
• Sábado, 30 de agosto 12:02:40 PDT 2008
• Sábado, 16 de agosto, 23:12:55 PST 292278994
• Domingo, 02 de dezembro, 08:47:04 PST 292269055

Mas e o ano 292278994?

Answer 1

Eu escrevi um substituto portátil para time.h (atualmente apenas localtime(), gmtime(), mktime() e timegm()) que usa tempo de 64 bits, mesmo em máquinas de 32 bits.Destina-se a ser incluído em projetos C como um substituto para time.h.Ele está sendo usado em Perl e pretendo corrigir os problemas de Ruby e Python 2038 com ele também.Isso fornece um intervalo seguro de +/- 292 milhões de anos.

Você pode encontrar o código no projeto y2038.Sinta-se à vontade para postar qualquer dúvida no rastreador de problemas.

Quanto ao "isso não será um problema por mais 29 anos", leia atentamente este lista de respostas padrão para isso.Resumindo, coisas acontecem no futuro e às vezes você precisa saber quando.eu também tenho uma apresentação sobre o problema, o que não é solução e o que é.

Ah, e não se esqueça de que muitos sistemas de tempo não lidam com datas anteriores a 1970.Coisas aconteceram antes de 1970, às vezes é preciso saber quando.

Answer 2

Você sempre pode implementar RFC 2550 e esteja seguro para sempre ;-)

O universo conhecido tem um passado e um futuro finitos.A idade atual do universo é estimada em [Zebu] entre 10 ** 10 e 2 * 10 ** 10 anos.A morte do universo é estimada em [Nigel] que ocorra em 10 ** 11 anos e em [Drake] como ocorrendo em 10 ** 12 anos para um universo fechado (o Big Crunch) ou 10 ** 14 anos para um universo aberto (a morte térmica do universo).

 

Os programas compatíveis com Y10K podem optar por limitar a faixa de datas que eles apoiam aos consistentes com a vida esperada do universo.Os sistemas compatíveis com Y10K devem aceitar datas Y10K de 10 ** 12 anos no passado para 10 ** 20 anos no futuro.Os sistemas compatíveis com Y10K devem aceitar datas por pelo menos 10 ** 29 anos no passado e no futuro.

Answer 3

O Visual Studio mudou para uma representação de time_t de 64 bits no Visual Studio 2005 (embora ainda deixe _time32_t para compatibilidade com versões anteriores).

Contanto que você tenha o cuidado de sempre escrever código em termos de time_t e não assuma nada sobre o tamanho, como sysrqb aponta, o problema será resolvido pelo seu compilador.

Answer 4

Acho que deveríamos deixar o bug lá.Então, por volta de 2036, poderemos começar a vender consultoria por grandes somas de dinheiro para testar tudo.Afinal, não foi assim que gerimos com sucesso o rollover de 1999-2000.

Eu estou apenas brincando!

Eu estava sentado em um banco em Londres em 1999 e fiquei bastante surpreso quando vi um consultor começar a testar a máquina de café no ano 2000.Acho que se aprendemos alguma coisa com esse fiasco, foi que a grande maioria dos softwares simplesmente funcionará e a maior parte do resto não causará colapso se falhar e pode ser consertada após o evento, se necessário.Como tal, eu não tomaria nenhuma precaução especial até muito mais perto da hora.

Answer 5

Dada a minha idade, acho que deveria pagar muito na minha pensão e pagar todas as minhas dívidas, então outra pessoa terá que instalar o software!

Desculpe, se você pensar no “valor presente líquido” de qualquer software que você escreve hoje, não terá efeito o que o software fará em 2038.Um “retorno sobre o investimento” de mais do que alguns anos é incomum para qualquer projeto de software, então você ganha muito mais dinheiro para seu empregador ao enviar o software mais rapidamente, em vez de pensar tão à frente.

A única exceção comum é o software que prevê o futuro. 2038 já é um problema para os sistemas de cotação de hipotecas.

Answer 6

Mantenha uma boa documentação e inclua uma descrição de suas dependências de tempo.Não creio que muitas pessoas tenham pensado em quão difícil pode ser essa transição, por exemplo, os cookies HTTP serão quebrados nessa data.

Answer 7

O que devemos fazer para nos preparar para 2038?

Esconda-se, porque o apocalipse está chegando.

Mas, falando sério, espero que os compiladores (ou as pessoas que os escrevem, para ser mais preciso) possam lidar com isso.Eles têm quase 30 anos.Espero que seja tempo suficiente.

Em que ponto começamos a nos preparar para o Y10K?Algum fabricante de hardware/laboratório de pesquisa procurou a maneira mais fácil de migrar para qualquer nova tecnologia que precisaremos por causa disso?

Answer 8

Trabalho com embarcado e pensei em postar nossa solução aqui.Nossos sistemas são de 32 bits, e o que vendemos agora tem garantia de 30 anos, o que significa que encontrarão o bug do ano 2038.Atualizar no futuro não era uma solução.

Para corrigir isso, definimos a data do kernel 28 anos antes da data atual.Não é um deslocamento aleatório, 28 anos é exatamente o tempo que levará para os dias da semana coincidirem novamente.Por exemplo, estou escrevendo isso em uma quinta-feira e a próxima vez que 7 de março será quinta-feira será em 28 anos.

Além disso, todos os aplicativos que interagem com datas em nossos sistemas irão converter a data do sistema (time_t) em um time64_t personalizado e aplicar o deslocamento de 28 anos à data correta.

Criamos uma biblioteca personalizada para lidar com isso.O código que estamos usando é baseado nisso: https://github.com/android/platform_bionic

Assim, com esta solução você pode facilmente ganhar 28 anos extras.

Answer 9

Em 2038, todas as bibliotecas de tempo deverão usar números inteiros de 64 bits, então isso não será um grande problema (em software que não seja completamente sem manutenção).

Os programas COBOL podem ser divertidos.

Answer 10

A palavra-chave é "deveria".

Se você precisar garantir a proteção futura, poderá construir sua própria classe de data/hora e usá-la, mas eu só faria isso se você acha que o que você escreve será usado no sistema operacional legado.