machine.RTC.datetime() seconds change out of sync with subseconds rollover

[JuhaS2]

I am reporting a bug.

While running MicroPython 1.19.1 on Teensy 4.1 I have noticed that the rtc.datetime() does not work as expected. When quickly polling the datetime from the built-in RTC, I can see that the second does not change at the same moment as subsecond rolls over.

(2022, 11, 28, 0, 14, 28, 32, 967416)
(2022, 11, 28, 0, 14, 28, 33, 967603)
...
(2022, 11, 28, 0, 14, 28, 33, 999868)
(2022, 11, 28, 0, 14, 28, 33, 70)

On documentation, it says "The meaning of the subseconds field is hardware dependent.", but I think this is very strongly undesired and unexpected output. If the subseconds-field is used directly as UTC microseconds, this causes there to be once per second a 33ms time window when the RTC returns time that is 1s off from the true time.

Minimal code for reproducing the output:

import machine
rtc = machine.RTC()
while True:
    print(rtc.datetime())

[robert-hh]

Thank you for the observation. The problem is by design and cannot be fixed. The MIMXRT10xx RTC module does not have a subsecond counter. It is emulated in the software, by taking the ticks_us64() counter with an offset. The offset is remembered when the time is set with datetime(). So there are two inherent problems:

• the clock sources for RTC and ticks_us64() are different. Even with both being crystal based there will be a drift over time.
• the values of the counters are taken at different times. The action not atomic. So there is a skew between the two, which is best about 1 ms, as you can see in your report.

The only alternative to the actual approach is not providing a subsecond reading at all. That's reliable.

[JuhaS2]

If it cannot be fixed, it would probably be a good idea to remove the subseconds from the datetime output. Incorrect data is worse than no data. To use the subseconds, the users now needs to implement their own corrections which they could just as well write around the machine.ticks_us().

[robert-hh]

We can consider dropping the subsecond value. But implemented in the driver as C-Code, the error is anyhow smaller than anything a use could implement using python. machine.tick_us() uses the same ticks_us() timer that is used for the implemented correction. So documenting it may be another option. The value still can be ignored.