This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients pitrou, vstinner
Date 2017-06-30.07:58:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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 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.
Date User Action Args
2017-06-30 07:58:35vstinnersetrecipients: + vstinner, pitrou
2017-06-30 07:58:35vstinnerlinkissue30807 messages
2017-06-30 07:58:35vstinnercreate