Como usar o tempo> ano de 2038 no oficial do Windows Python 2.5

Question

O Python oficial 2.5 no Windows foi construído com Visual Studio.Net 2003, que usa 32 bit time_t. Assim, quando o ano é de> 2038, apenas dá exceções.

Embora este é fixa em Python 2.6 (que mudou time_t de 64 bits com VS2008), eu gostaria de usar 2.5 porque muitos módulos já estão compilados para ele.

Então aqui está a minha pergunta - há qualquer solução para deixar facilmente o meu punho programa no ano> 2038 e ainda usando Python oficial 2.5? Por exemplo, algumas bibliotecas pré-fabricados como "time64" ou "antigo" etc ...

Por favor, não me diga para atualizar para 2.6+ ou esquecer o bug -. Eu tenho minha razão de necessidade de fazê-lo funcionar, é por isso que eu postar a pergunta aqui

Answer 1

A melhor solução que eu encontrei é para obter uma cópia fonte de Python 2.5, e re-compilar o módulo tempo com compiladores cujo padrão time_t de 64 bits, por exemplo, VS2005 ou VS2008 (também pode configurar o tempo de execução C para prevenir side-by-side edição).

Answer 2

O módulo datetime na biblioteca padrão deve funcionar bem para você. O que você precisa a partir do módulo time que datetime não oferece?

Answer 3

Eu não quero banal som, mas por que não:

• esquecer o bug Y2038 com Python 2.5
• atualizar para Python 2.6 em algum momento no futuro antes de 2038

Editar: Para esclarecer: (e estou falando sério - Eu não tive a intenção de zombar)

Provavelmente, você pode atualizar Python para 2,6 (ou posterior) em algum tempo indefinido entre agora e 2038. Talvez em 2012. Talvez em 2015. Talvez em 2037.

Se você está ciente das diferenças entre a variável timestamp Python em seu aplicativo (eu não sou muito de um usuário Python), parece que estes seriam os aspectos importantes a considerar:

• o que os dados estão sendo salvos persistentemente
• como uma variável de 2,5 timestamp Python que tem sido persistiu, é restaurado usando Python 2.6 (presumivelmente ele irá "fazer a coisa certa")
• se os dados antigos serão armazenadas na sua forma persistente o suficiente para ambigüidades a surgir (por exemplo, o ano "96" é inequívoca quando consideradas entre 1950 e 2049, mas se que os dados são mantidos em torno até o ano de 2230, em seguida, "96" poderia ser 1996, 2096 ou 2196)

Se as respostas forem favoráveis, é só usar o timestamp regular com seu 2038 bug. Você terá que comparar isso com a quantidade de redesenho / refatoração você teria que fazer para que o aplicativo funcione com um timestamp alternativo (por exemplo, uma seqüência timestamp banco de dados ou qualquer outro).