Author haypo
Recipients haypo, pitrou
Date 2017-06-30.07:58:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwYXGfCJqr5PnGtSR+g_96EJq4btZh6VSHBdwmnieuwOCg@mail.gmail.com>
In-reply-to <1498809041.41.0.118257591446.issue30807@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2017-06-30 07:58:35hayposetrecipients: + haypo, pitrou
2017-06-30 07:58:35haypolinkissue30807 messages
2017-06-30 07:58:35haypocreate