The official Python 2.5 on Windows was build with Visual Studio.Net 2003, which uses 32 bit time_t. So when the year is > 2038, it just gives exceptions.
Although this is fixed in Python 2.6 (which changed time_t to 64 bit with VS2008), I'd like to use 2.5 because many modules are already compiled for it.
So here's my question - is there any solution to easily let my program handle year > 2038 and still using official Python 2.5? For example some pre-made libraries like "time64"
or "longtime" etc...
Please do not tell me to upgrade to 2.6+ or forget about the bug - I have my reason to need to make it work, that's why I post the question here.
The datetime
module in the standard library should work fine for you. What do you need from module time
that datetime
doesn't offer?
I don't mean to sound trite, but why not:
edit: To clarify: (and I'm serious — I didn't mean to poke fun)
Presumably you can upgrade Python to 2.6 (or later) at some indefinite time between now and 2038. Maybe in 2012. Maybe in 2015. Maybe in 2037.
If you are aware of the differences between the Python timestamp variable in your application (I'm not much of a Python user), it seems like these would be the important aspects to consider:
If the answers are favorable, just use the regular timestamp with its 2038 bug. You'll have to compare that with the amount of redesign/refactoring you'd have to do to make your application work with an alternate timestamp (e.g. a database timestamp string or whatever).
The best solution I've found is to get a source copy of Python 2.5, and re-compile the time module with compilers which defaults time_t to 64 bit, for example VS2005 or VS2008 (may also configure the C runtime to prevent side-by-side issue).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With