Overflow converting -2147483648 to int when using MPZ
When MICROPY_LONGINT_IMPL == MICROPY_LONGINT_IMPL_MPZ, calling mp_obj_get_int() for a Python variable that contains the value -2147483648 results in an overflow converting long int to machine word error.
If MICROPY_LONGINT_IMPL == MICROPY_LONGINT_IMPL_LONGLONG instead, the conversion works OK.
Is the MPZ overflow check incorrect?
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?