QUERY · ISSUE
No format of tzinfo accepted in RTC.init()
Documentation defines RTC.init() method accepting tzinfo argument:
.. method:: RTC.init(datetime)
Initialise the RTC. Datetime is a tuple of the form:
``(year, month, day[, hour[, minute[, second[, microsecond[, tzinfo]]]]])``
But not just that that docu doesn't specify format (Object/String) of the tzinfo it also "doesn't work".
CANDIDATE · ISSUE
ports/rtc: Inconsistencies between ports and the documentation.
ports
It looks like the machine.rtc() API is different for all ports and to the documentation.
- to start with the good part: In all ports rtc.datetime() matches the machine.RTC class documentation.
- rtc.init() for the cc3200 works as documented
- rtc.init() differs from the documentation in the item order of the datetime tuple for the ports esp32, samd, mimxrt.
- no rtc.init() at the rp2 port.
- rtc.init() at the stm32 and renesas.ra port just reinit's the RTC device and ignores the function argument.
- rtc.now() is only available in the cc3200 and mimxrt port.
- the documentation for rtc.datetime() is different between the machine.RTC class section and the quickref for the ports stm32, rp2, mimxrt, esp32, esp8266, renesas-ra,
So it seems as if the documentation of rtc.init() and rtc.now() only matches the cc3200 port. I can make that all consistent, but we should agree first on which class methods should be available. So a simple approach would be:
- keep rtc.datetime() as it is now. Maybe add it to the cc3200 port. It is not consistent to CPython datetime.datetime, but that topic has been discussed several times already with the decision to keep the actual rtc.datetime format.
- drop rtc.now() from the mimxrt port. Only keep it at the CC3200 port for legacy.
- drop the set date/time functionality of rtc.init() and/or change at least the documentation.
- fix the inconsistencies in the documentation.
Edit: Created PR #10607