It's easy to miss and took me quite some time to figure out the issue.I was just about to post that I had discovered the day being in a different place
I would actually strengthen my recommendation to; never use 'rtc' except where forced to such as when setting the time, as you need to when using NTP.
The RTC is a PITA. The rtc.datetime() tuple represents exactly what would have been sequentially read from or written to an external battery backed-up real-time clock chip at some time in the past, hence why its format is different and incompatible with what 'time' uses, and day of week numbering will usually be different as well. That was a source of persistent and confusing bugs in earlier versions of MicroPython for RP2040 but do now appears to have been resolved.
Two thing you are inevitable going to ask about in the future; time zone and daylight saving time. My recommendation is to permanently keep the RTC and 'time' on GMT/UTC and create a wrapper module around those to deliver what you need. Have that perform the adjustments rather than altering the RTC time itself.
And cross-posted with -
Sure is IMO, even with desktop Python. I can't remember the exact details but I recall it comes down to 'time.gmtime()' and 'time.localtime()' giving correct results -Is there a timezone issue with time.time()?
Code:
Python 3.7.3 (default, Mar 23 2024, 16:12:05)>>> import time>>> t = time.time()>>> time.gmtime(t)[:](2024, 4, 25, 13, 1, 48, 3, 116, 0)>>> time.localtime(t)[:](2024, 4, 25, 14, 1, 48, 3, 116, 1)
Within MicroPython there is no issue, no conflict or confusion, because it doesn't support time zones or DST - That's your problem to resolve

Statistics: Posted by hippy — Thu Apr 25, 2024 12:55 pm