Come usare il tempo > anno 2038 su Windows Python 2.5 ufficiale

Question

Il Python 2.5 ufficiale su Windows è stato creato con Visual Studio.Net 2003, che utilizza time_t a 32 bit. Quindi quando l'anno è > 2038, dà solo delle eccezioni.

Anche se questo è stato risolto in Python 2.6 (che ha cambiato time_t a 64 bit con VS2008), mi piacerebbe usare 2.5 perché molti moduli sono già stati compilati per questo.

Quindi, ecco la mia domanda: esiste qualche soluzione per consentire al mio programma di gestire l'anno > 2038 e stai ancora usando Python 2.5 ufficiale? Ad esempio alcune librerie prefabbricate come " time64 " o " longtime " ecc ...

Per favore, non dirmi di aggiornare alla versione 2.6+ o di dimenticare il bug. Ho il motivo per cui devo farlo funzionare, ecco perché inserisco la domanda qui.

Answer 1

La migliore soluzione che ho trovato è quella di ottenere una copia sorgente di Python 2.5 e ricompilare il modulo temporale con compilatori che per impostazione predefinita time_t a 64 bit, ad esempio VS2005 o VS2008 (può anche configurare il runtime C per impedire problema affiancato).

Answer 2

Il modulo datetime nella libreria standard dovrebbe funzionare bene per te. Cosa ti serve dal modulo time che datetime non offre?

Answer 3

Non intendo sembrare banale, ma perché no:

• dimentica il bug Y2038 con Python 2.5
• esegui l'aggiornamento a Python 2.6 in futuro prima del 2038

modifica Per chiarire: (e sono serio, non volevo scherzare)

Presumibilmente puoi aggiornare Python alla 2.6 (o successive) a tempo indefinito tra oggi e il 2038. Forse nel 2012. Forse nel 2015. Forse nel 2037.

Se sei consapevole delle differenze tra la variabile timestamp di Python nella tua applicazione (non sono un grande utente Python), sembra che questi sarebbero gli aspetti importanti da considerare:

• quali dati vengono salvati in modo persistente
• come una variabile timestamp Python 2.5 che è stata perseverata, viene ripristinata usando Python 2.6 (presumibilmente farà "fare la cosa giusta")
• se i vecchi dati saranno conservati nella sua forma persistente abbastanza a lungo da far sorgere ambiguità (ad esempio l'anno "96" non è ambiguo se considerato tra il 1950 e il 2049, ma se tali dati sono conservati fino all'anno 2230, allora " 96 "potrebbe essere 1996, 2096 o 2196)

Se le risposte sono favorevoli, basta usare il normale timestamp con il suo bug 2038. Dovrai confrontarlo con la quantità di riprogettazione / refactoring che dovresti fare per far funzionare la tua applicazione con un timestamp alternativo (ad esempio una stringa di timestamp del database o altro).