-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Closed
Labels
portsRelates to multiple ports, or a new/proposed portRelates to multiple ports, or a new/proposed port
Description
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
Metadata
Metadata
Assignees
Labels
portsRelates to multiple ports, or a new/proposed portRelates to multiple ports, or a new/proposed port