[Kevin Jacobs, on strptime] > I've just retested with my original code and it does look like Brett has > indeed fixed it. Or at least fixed it to the point that mktime doesn't > croak on Linux, Solaris, Tru64, and IRIX with our app. Great! Hats off to Brett. >> ... the problem is that how strptime behaves varies in fact across >> boxes. > Or more importantly that strptime is now standardized in Python, while > mktime is not. Ya, that one's a real problem. The new-in-2.3 datetime module supplies a saner way to deal with dates & times, but is new, and is probably lacking some features some people need. The problem with mktime() is that Python also wants nice ways to play with random C libraries on your platform, and platform mktime() implementations are *really* different (they vary in their beliefs about when "the epoch" begins, what the first representable year is, what the last representable year is, and whether leap seconds exist; POSIX gives clear snswers to the first and last, explicitly gives up on the middle two, and not all Python platforms try to follow POSIX anyway). So I expect mktime() will remain a cross-platform mess forever -- else Python wouldn't play nice with the mess that is your platform <0.9 wink>. > Given that my previous problems with the Python strptime have been > addressed, I am now +1 on using it (although I'm still going to > avoid it and mktime in my code as much as possible). Unfortunately, datetime doesn't supply a wholly sane way to do strftime yet, and no way to do strptime. The ISO formats are very easy (by design) to parse, so those might be best to use in portable code.
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