Need to address inconsistencies between mktime and localtime.
Currently, if I do:
>>> time.localtime(-1072915200)
(1966, 1, 1, 0, 0, 0, 5, 1)
>>> time.mktime((1966, 1, 1, 0, 0, 0, 5, 1))
3222052096
>>> time.localtime(3222052096)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: overflow converting long int to machine word
>>> hex(3222052096)
'0xc00c9d00'
>>> hex(0x80000000 - 1072915200)
'0x400c9d00'
I think that time.mktime((1966, 1, 1, 0, 0, 0, 5, 1)) should return the negative representation. However, I noticed that timeutils_seconds_since_2000 returns an mp_uint_t rather than an mp_int_t
So a couple of questions came to mind:
1 - Do we want to support times from 1966 to 2000 (which is the -ve small int range)?
2 - Should we support mpz ints?
3 - Adding full support for mpz ints seems like overkill, but we could get 1 extra bit by allowing mpz ints in the full 32-bit range to be supported. Then we'd be able to support dates from 2000 +/- 68 years. This would only require a slightly different conversion into and out of the timeutils functions. The actual code itself wouldn't need to change.
Thoughts?
lib/timeutils: Fix problem with dates prior to Mar 1, 2000
The easiest way to see this is to do:
>>> import time
>>> time.localtime(0)
(2000, 1, 1, 0, 0, 0, 5, 1)
>>> time.localtime(1)
(2000, 1, 2, 233, 197, 197, 6, 2)
With this patch, we instead get:
>>> import time
>>> time.localtime(1)
(2000, 1, 1, 0, 0, 1, 5, 1)
Doh - In C % is NOT a modulo operator, it's a remainder operator.