Skip Montanaro added the comment: Jon> Almost everything you just said about time_t is wrong. time_t is Jon> signed, and always has been (otherwise the 'end of time' for 32-bit Jon> time_t would be 2106, not 2038). Also, time_t does not end at 2038 Jon> because nothing says it must be 32 bits. Also, Python has 'long Jon> integers' which do not overflow.
My apologies about goofing up on the signedness of time_t. What are you going to do with a long integer that you can't do with a datetime object? You clearly can't pass it directly to any Unix library functions which expect time_t. Converting it can overflow. Jon> Also, I don't understand what you mean about use cases. The "use Jon> case" is "dealing with anything which expects standard Unix time_t, Jon> for example the Python standard library". The use case I have Jon> personally is the program I was working on when I encountered the Jon> problem described in this bug report. Also I think symmetry is a Jon> darn good argument. Why does fromtimestamp exist if, as you claim, Jon> nobody uses time_t? What should datetime.datetime(9999, 1, 1).totimestamp() return? How would you pass it to something which accepts a time_t? The fromtimestamp functions work simply because the range of time_t is a proper subset of the range of Python's datetime objects. Symmetry gets you little. In situations where you need Unix timestamps and you know your datetime objects are within the bounds representable by time_t, you can define a convenience function: def totimestamp(dt): return time.mktime(dt.timetuple()) + dt.microsecond/1e6 This will, of course, fail if the year is too big or too small (and will fail in platform-dependent ways if the underlying platform's range of representable dates has different bounds than Unix does). Doing it without resorting to calling time.mktime is also nontrivial. Under the covers the datetime module currently uses platform functions to get time information anyway. It doesn't do a lot of low-level time arithmethic itself. Implementing fromtimestamp would require a fair amount of effort unless you were willing to punt and just raise OverflowError for dates outside the system's range. Skip _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1673409> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com