Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to use time > year 2038 on official Windows Python 2.5

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.

like image 546
Francis Avatar asked May 08 '09 13:05

Francis


3 Answers

The datetime module in the standard library should work fine for you. What do you need from module time that datetime doesn't offer?

like image 155
Alex Martelli Avatar answered Nov 13 '22 22:11

Alex Martelli


I don't mean to sound trite, but why not:

  • forget about the Y2038 bug with Python 2.5
  • upgrade to Python 2.6 at some point in the future before 2038

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:

  • what data is being saved persistently
  • how a Python 2.5 timestamp variable that has been persisted, gets restored using Python 2.6 (presumably it will "do the right thing")
  • whether old data will be stored in its persistent form long enough for ambiguities to arise (e.g. the year "96" is unambiguous when considered between 1950 and 2049, but if that data is kept around until the year 2230 then "96" could be 1996, 2096, or 2196)

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).

like image 38
Jason S Avatar answered Nov 13 '22 22:11

Jason S


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).

like image 4
Francis Avatar answered Nov 13 '22 23:11

Francis