Message297350
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. |
|
Date |
User |
Action |
Args |
2017-06-30 07:58:35 | vstinner | set | recipients:
+ vstinner, pitrou |
2017-06-30 07:58:35 | vstinner | link | issue30807 messages |
2017-06-30 07:58:35 | vstinner | create | |
|