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?
rp2: time epoch differs from Pyboard and docs.
The docs state that for embedded ports the epoch is 2000.
I retrieve time from an NTP server and apply an offset of 3155673600 to convert from 1900 to 2000. This was calculated from
>>> from datetime import date
>>> (date(2000, 1, 1) - date(1900, 1, 1)).days * 24*60*60
3155673600
This produces correct results on Pyboards when passed to time.localtime(). On the rp2 it produces correct dates and times except that the year is 1991.
Is this intentional?