6

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.

Francis
  • 11,388
  • 2
  • 33
  • 37
  • 2038 is a long way away... don't worry about it. – Dead account May 08 '09 at 13:22
  • 4
    people used to consider 2000 a long way in the 80/90s, that's why we have the Y2K bug... – Francis May 08 '09 at 13:23
  • 1
    Store the date as a string like: "20080122". Optimize it by removing redundant zeros. So that becomes: "8-12-2". You know that it's year 2000, so 2 is not needed. After that store it in an XML file for easy access as: 8122thu If you use this throughout your application then you will have no problems and no need for built in date type. – Andriy Drozdyuk May 08 '09 at 13:29
  • What Python module/function/class are you referring to? Can you give a code example? – Ber May 08 '09 at 13:32
  • Why does time_t break down in year 2038, not 2048? – Nikhil May 09 '09 at 02:21
  • because signed 32 bit time_t will overflow on year 2038. – Francis May 09 '09 at 03:21
  • 1
    I need at least time.time() and time.localtime() to work correctly, for both if user input > year 2038 or change system clock to year 2038. – Francis May 09 '09 at 03:23
  • You need time.time()/time.localtime() (and datetime.now() to work now and up to the year 2038 and you can't upgrade to Python 2.6 during that time? And you can't explain why that's your requirement? May I suggest some consultants I know who can solve this problem for you? After all, you must surely have some maintenance budget to keep the systems operating for the next 28 or so years. – Andrew Dalke Dec 08 '09 at 09:42
  • 1
    @dalke: I think the answer is easy - if you are trying to fix a minor bug for a large system, you won't want to upgrade entire runtime interpreter, and that's my situation. For example, imagine you are maintaining a web service site (and lots of extension already installed); some user told you that time failed to work and they want it fixed, but you won't want to upgrade python because more user may get into trouble by upgrading. It's all about stability and reducing risks. – Francis Dec 09 '09 at 08:06

3 Answers3

7

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

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • did you ever tried datetime? datetime is not based on time_t, and it does not support time_t64, either (try datetime.datetime.fromtimestamp(LARGE_NUMBER_HERE) ) – Francis May 08 '09 at 14:37
  • @Francis: I also use datetime. Not based on time_t doesn't have much impact. What's wrong with using datetime? Any specific bugs or problems? – S.Lott May 08 '09 at 14:47
  • 2
    Yes. datetime does not help - if I need to get a time_t like time.time(), passing Y2039 to datetime will fail with the message "ValueError: timestamp out of range for platform time_t". If you change your system clock to Year 2039, calling datetime.date.today() also fail as "ValueError: timestamp out of range for platform localtime() function". So, datetime does not change anything - it's simply a wrapper to default time module. – Francis May 08 '09 at 15:31
7

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

Jason S
  • 184,598
  • 164
  • 608
  • 970
  • python 2.6 is using vc8 side by side runtime, so I don't want to change it right now (many modules would fail). – Francis May 08 '09 at 14:33
  • +1: Put a note in your Outlook calendar for July of 2037 to do the upgrade. – S.Lott May 08 '09 at 14:48
  • 8
    Why all the snide responses? Perhaps the application actually needs to represent dates beyond 2038 _today_. I dunno, perhaps its a geological data app that needs to associate predictions with long term dates or something. – Nick May 08 '09 at 16:38
  • I'm not saying to upgrade to 2.6 now... I mean in the future when you are ready to do so. Edit forthcoming. – Jason S May 08 '09 at 16:58
  • ok, see my edits. It just seems to me (I don't know your application) that by the time you are close enough to worrying about the Y2038 bug, you'll have already upgraded Python to something newer than version 2.5, in which case persistent data records are the only worry. – Jason S May 08 '09 at 17:12
  • There's one small problem with 2.6 that is solved by sticking with 2.5. If you use py2exe, you will run into DLL hell if you don't install MSVCRT with windows SXS, instead of just plopping the file in the same directory. – Unknown May 09 '09 at 02:24
  • "geological data" needs more than the dates between Y0000 and Y9999 which datetime supports, as well as a different representation, like ("23.2 mya" for "23.2 million years ago"). – Andrew Dalke Dec 08 '09 at 09:38
  • yeah seriously, do this. this is one advantages of interpreted languages! – Matt Joiner Feb 13 '10 at 16:44
5

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

Francis
  • 11,388
  • 2
  • 33
  • 37