Cómo usar el tiempo > año 2038 en Windows Python 2.5 oficial

Question

El Python 2.5 oficial en Windows fue compilado con Visual Studio.Net 2003, que usa time_t de 32 bits. Entonces, cuando el año es > 2038, solo da excepciones.

Aunque esto se solucionó en Python 2.6 (que cambió time_t a 64 bit con VS2008), me gustaría usar 2.5 porque muchos módulos ya están compilados para él.

Entonces, esta es mi pregunta: ¿hay alguna solución para permitir que mi programa maneje año > 2038 y sigues usando Python 2.5 oficial? Por ejemplo, algunas bibliotecas prefabricadas como " time64 " o " longtime " etc ...

Por favor, no me diga que actualice a 2.6+ o que me olvide del error: tengo mi razón para necesitar que funcione, por eso publico la pregunta aquí.

Answer 1

La mejor solución que he encontrado es obtener una copia fuente de Python 2.5 y volver a compilar el módulo de tiempo con compiladores que predeterminan time_t a 64 bits, por ejemplo VS2005 o VS2008 (también puede configurar el tiempo de ejecución C para evitar problema lado a lado).

Answer 2

El módulo datetime en la biblioteca estándar debería funcionar bien para usted. ¿Qué necesita del módulo time que datetime no ofrece?

Answer 3

No quiero parecer trivial, pero ¿por qué no?

• olvídate del error Y2038 con Python 2.5
• actualizar a Python 2.6 en algún momento en el futuro antes de 2038

editar: Para aclarar: (y lo digo en serio, no quise burlarme)

Presumiblemente puede actualizar Python a 2.6 (o posterior) en algún momento indefinido entre ahora y 2038. Quizás en 2012. Quizás en 2015. Quizás en 2037.

Si conoce las diferencias entre la variable de marca de tiempo de Python en su aplicación (no soy muy usuario de Python), parece que estos serían los aspectos importantes a considerar:

• qué datos se guardan de forma persistente
• cómo se restaura una variable de marca de tiempo de Python 2.5 que se ha persistido, usando Python 2.6 (presumiblemente "hará lo correcto")
• si los datos antiguos se almacenarán en su forma persistente el tiempo suficiente para que surjan ambigüedades (por ejemplo, el año "96" no es ambiguo cuando se considera entre 1950 y 2049, pero si esos datos se mantienen hasta el año 2230, entonces "" 96 '' podría ser 1996, 2096 o 2196)

Si las respuestas son favorables, solo use la marca de tiempo regular con su error 2038. Tendrá que comparar eso con la cantidad de rediseño / refactorización que tendría que hacer para que su aplicación funcione con una marca de tiempo alternativa (por ejemplo, una cadena de marca de tiempo de base de datos o lo que sea).