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

views:

534

answers:

+4 Q:

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.

+5 A:

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 2009-05-08 13:34:27

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 2009-05-08 14:37:09

@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 2009-05-08 14:47:21

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 2009-05-08 15:31:43

+7 A:

Jason S 2009-05-08 13:35:51

ooh thats good .(15 char limit dot!)

drozzy 2009-05-08 13:43:14

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 2009-05-08 14:33:30

+1: Put a note in your Outlook calendar for July of 2037 to do the upgrade.

S.Lott 2009-05-08 14:48:05

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 2009-05-08 16:38:30

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 2009-05-08 16:58:59

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 2009-05-08 17:12:02

Nick: you do have a point though.

Jason S 2009-05-08 17:58:20

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 2009-05-09 02:24:39

"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 2009-12-08 09:38:24

yeah seriously, do this. this is one advantages of interpreted languages!

Matt Joiner 2010-02-13 16:44:53

+2 A:

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 2009-12-08 09:17:53

ansaurus

tags:

views:

answers:

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

related questions