STINNER Victor added the comment: Antoine Pitrou added the comment: > It seems _PyTime_ObjectToTimeval() would be better here. What do you think?
Oh, I forgot to document why _PyTime_ObjectToTimeval() still exists :-) The _PyTime_t type supports a range of [-292 years, +292 years]: it's enough to pass a timeout value to select.select() or signal.setitimer(). But it's not enough to pass a timestamp relative to the UNIX Epoch (1970-01-01 00:00), since we want to support crazy dates like up to (0001-01-01 00:01) in the datetime module. So the datetime module uses _PyTime_ObjectToTimeval() to use internally the time_t type which supports a range of +/- 292,271,023,045 years when time_t is 64-bit long (which becomes the case on most platforms) :-) I would prefer to just fix _PyTime_FromSecondsObject() to handle correctly decimal.Decimal, rather than using _PyTime_ObjectToTimeval(). I tried to write an exhaustive test suite for _PyTime_FromSecondsObject() which all corner cases, whereas _PyTime_ObjectToTimeval() is less well tested and I would like to kill it (but I don't know how at this point ;-)). I can work on a patch, but not right now. You can fix the bug differently if you prefer to not use pytime. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30807> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
