#UTIME MICROPYTHON HOW TO#
#UTIME MICROPYTHON CODE#

One way to do that would be an in-place RTC.datetime() method to which you pass a pre-allocated list which the method then populates with year/month/day/etc. Even adding time.time_ns() would also be useful since some things can provide and use such fine resolution.Д«ut then remains the question about getting absolute time values without memory allocation. So having time.time() already return the value with the 1970 Epoch I think is acceptable from a requires-big-int-and-memory-allocation point of view.ДЇor getting sub-second, absolute time values, suggests in #5973 to add time.time_us() which returns a big-int. But such an adjustment value is already a big-int, so you necessarily have a requirement on big-int support in the firmware, and also memory allocation for the big-int and its arithmetic operations. Note: currently the way to make time.time() compatible with 1970 Epoch is to adjust it by the correct amount (seconds between 19), and this is how the ntptime.py module works. On systems without big-ints enabled, they cannot include a sensible implementation of time.time(). (Although there's an argument that if it can return sub-second accuracy then it's not working as expected from CPython sa shouldn't exist at all, but I think it's an ok compromise to return a big-int if 64-bit floats are not available.)

#UTIME MICROPYTHON CODE#

Code would then work 'as expected', except you don't get sub-second accuracy. On systems with only 32-bit float it cannot return a float because floats can't represent the number with 1 second accuracy. If it can't do that then the function should not exist. My opinion now (as opposed to 6 years ago when time.time() was added to the stm port: d6cbbc5) is that, since it's called time.time(), it should return the same logical value as CPython, ie Epoch of 1970. And since time in general is hard to get right, this makes it unnecessarily harder. this is a pretty significant difference from CPython (and the unix world) and has pretty far reaching consequences. I would consider changing the MicroPython-epoch to the standard 1970 one. The world thinks it's 1970, MP thinks it's 2000. Reply to this email directly, view it on GitHub You are receiving this because you are subscribed to this thread. Native module for the esp32 that uses the lwip sntp and std C timeДЇunctions and forget about RTC and utime. It seems easier to just write a dynamically loadable

#UTIME MICROPYTHON HOW TO#

I'm not sure how to fix this without spending a lot of work with an The utime localtime and mktime are a hazard given the they Module can of course be useful if Wifi is off, etc, but it's kind'aДuplicated code. To manipulate time (gettimeofday, mktime, localtime, etc). The lwip sntp client does what you'd expect it to do and On a connected board, such as esp or pybd, the existing RTC and utime make Pyboard over USB or by app code using the GPS. It's very little code, the RTC can be set via MP board, such as a pyboard perhaps with a GPS module the existing RTC and I looked at the machine.RTC mess, utime, #5733 On Sat, at 12:04 AM Thorsten von Eicken wrote:Д«ackground: I'm trying to enable lwip's sntp client on the esp32 and it's It seems easier to just write a dynamically loadable native module for the esp32 that uses the lwip sntp and std C time functions and forget about RTC and utime. I'm not sure how to fix this without spending a lot of work with an uncertain outcome. On the pybd all this is not a huge issue 'cause there's no SNTP. The utime localtime and mktime are a hazard given the they use a different epoch than lwip. The machine.RTC module can of course be useful if Wifi is off, etc, but it's kind'a duplicated code. There's a good set of std C functions to manipulate time (gettimeofday, mktime, localtime, etc). The lwip sntp client does what you'd expect it to do and steps or slews the RTC (your choice). On a connected board, such as esp or pybd, the existing RTC and utime make much less sense. It's very little code, the RTC can be set via pyboard over USB or by app code using the GPS.

On an unconnected MP board, such as a pyboard perhaps with a GPS module the existing RTC and utime make a lot of sense. I looked at the machine.RTC mess, utime, #5733 and #5553. Background: I'm trying to enable lwip's sntp client on the esp32 and it's not going so well.

Utime micropython