mal> Tim Peters wrote:
>>
>> [Skip Montanaro about deficiencies in the time module]
mal> Why don't you use mxDateTime ? It provides a platform independent
mal> layer on top of all the C lib confusion underneath.
mal> Also, the representable time range is
mal> -5851455-01-01 00:00:00.00 - 5867440-12-31 00:00:00.00
mal> ... should cover most people's needs ;-)
I think we're getting a bit far removed from the original context here. I'm
quite well aware of mx.DateTime and use it in my own code. I was assigned a
bug report about the calendar module:
http://sourceforge.net/tracker/?func=detail&aid=434143&group_id=5470&atid=105470
nThe tail end of the traceback is a ValueError generated by time.mktime
whose message suggests that it accepts years in the range 00-99 and 1900+.
I don't think it's reasonable to try and make time.mktime "work", so I
propose that we make the documentation and exception messages more
forthcoming about its platform-dependence.
Personally, I think adding mx.DateTime to the core wouldn't be a bad idea.
Python's date manipulation code is in need of some more cojones. 2.2 is
probably too near, but that's ultimately for the PythonLabs folks to decide.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4