MicroPython Forum (Archive)

On an ESP32 with generic v1.11 micropython I get what appears (to me) to be an inconsistency with time:
Output: I'd expect the outputs to match, within a few seconds, perhaps. What am I doing wrong?

Thanks!

Hi ttmetro,

The tuple for time.localtime and RTC.datetime are not identical, there is a small difference between them.

time.localtime gives (year, month, day, hour, minute, second, weekday, yearday)
RTC.datetime gives (year, month, day, weekday, hours, minutes, seconds, subseconds)

subseconds is microseconds on the ESP32, a value between 0 and 1000000.
But notice that the weekday is in a different place. Also time.localtime has a yearday, where as RTC.datetime has subseconds.

Should these tuples be the same? Probably! But in v1.11 they are not. Hope this helps.

Thanks! Indeed an unfortunate discrepancy.

nevercast wrote: ↑

Fri Dec 06, 2019 8:45 am

Should these tuples be the same? Probably! But in v1.11 they are not. Hope this helps.

Can they be the same?

Python's time.struct_time has the exact same 9 fields as the Unix ctime struct tm has (just in a different order). Since that is a standard coming from so high up, changing this format is out of the question.

However, RTC.datetime provides microseconds (at least on the ESP32), which would be lost if we made them the same. Not desirable.


Regards, Jan

Trouble is that although sensible, this change could break existing code. Hence we are stuck with it, at least until MicroPython 2.0.

I think there is a case for the machine module to have an RTC class with standard behaviour, with port-specific modules like pyb having hardware specific extensions and behaviours. The machine version would inevitably have reduced functionality common to all RTC hardware.

Whats the résumé ?

Prefere time.localtime for compatibility and use it if microseconds are not needed?

jedie wrote: ↑

Sun Dec 08, 2019 11:16 am

Prefere time.localtime for compatibility and use it if microseconds are not needed?

This is my preference. Use `time` until you need special `RTC` behaviour. I'm not sure if moving weekday in the RTC tuple to the same place in the localtime tuple actually helps anyone. Without checking the format on the docs, you might still assume they're the same.

While it might have been good for them to be identical from the start, or closer to it, they aren't so ttmetro is correct that it's kind of stuck that way until MicroPython goes through a breaking change version bump. (For what its worth, MicroPython doesn't have semantic versioning, but non-breaking changes is always preferred over breaking changes.)

While playing with ntptime (to send sensor data to a graphite server) I noticed that our current implementation

• completely ignores fractional seconds,
• makes absolutely no attempt to figure out any kind of round trip delay,
• has no methods to update the clock periodically without risking to block the whole system for a second if a UDP packet gets lost,
• should mention in the docs that one can set the host attribute if one has a local NTP server, which will greatly reduce the chance of lost packets.

I don't mean to go all the way with the statistical analysis of multiple round trips. But just measuring t0..t3 and then adding microseconds to the machine.RTC().datetime() call could get the MCU within a couple milliseconds. Right now it is on average half a second off because the code truncates everything to full second.


Regards, Jan

It is rather rudimentary. If you felt like writing an improved version and hosting it on GitHub I'm sure there would be quite a few takers.