QUERY · ISSUE

time.mktime() returns incorrect Unix timestamp on ESP32

openby jurijpopened 2024-12-28updated 2025-11-06

docs

Port, board and/or hardware

sysname='esp32', nodename='esp32', release='1.24.1', version='v1.24.1 on 2024-11-29', machine='Generic ESP32 module with ESP32. Unique ID b'\x94\xe6\x86\x13o$' (not sure what this is

MicroPython version

release='1.24.1', version='v1.24.1 on 2024-11-29',
When using this board and setting time using the ntp library thus ntptime.settime() this synchronizes the RTC to UTC using an NTP server, and it seems to be working correctly since time.localtime() returns (2024, 12, 28, 18, 11, 1, 5, 363) (UTC time). As I understand it, this should reset the real time clock to the current time. If I then set time.mktime(time.localtime()) which should provide the Unix time, it does not, instead is spits out 788726670 which is 1994-12-29 18:44:30 UTC. Can someone please explain this ? Is it a a bug? Bottom line, how can the realtime clock be set to a specific time?

Reproduction

from machine import RTC
import time

Manually set the RTC to a known time (e.g., 2024-01-28 15:30:00 UTC)

rtc = RTC()
rtc.datetime((2024, 1, 28, 0, 15, 30, 0, 0)) # (year, month, day, weekday, hour, minute, second, subseconds)

Get the Unix timestamp

unix_time = time.mktime(time.localtime())

print("Unix time:", unix_time)

Result: Unix time: 759771000 it should be closer to 1735413856.203176

Expected behaviour

Expected the unix time to be determined correctly. That is it should look something like this 1735413022.697727

Observed behaviour

The output is incorrect - see Expected behaviour result above

Additional Information

No, I've provided everything above.

Code of Conduct

Yes, I agree

CANDIDATE · PULL REQUEST

esp32/time: make utime conform to CPython

closedby tveopened 2020-04-26updated 2025-01-14

port-esp32

This PR attempts to start fixing some of the issues with utime and machine.RTC, per #5969, #5553, #5733. The overall idea is to flesh out utime so it is (a) compatible with CPython and (b) fully-featured to manage the time and (internally) query/set the RTC. The RTC.datetime method would then be deprecated but left in-place for code compatibility and possibly for minimal ports that don't have utime (I have not looked at that aspect).

What this PR currently does is in the esp32 port:

change utime.localtime and utime.mktime to conform to the CPython standard 9-tuple (well, actually to the 9 11-tuple elements that have numeric indexes).
change the Epoch to be the POSIX 1970 Epoch.
add utime.gmtime and time.tzset so one can set a time zone and query UTC as well as local time. The implementation of tzset does not conform to CPython in that it takes a zone specification whereas in CPython it takes no argument and the zone is set via the TZ environment variable.
add utime.settime and utime.adjtime as extensions WRT CPython so one can step the time or gradually adjust the time.
add a network.SNTP class with methods to start SNTP, stop SNTP, and get the SNTP status (this is only partially implemented in this PR and is intended to leverage the LwIP SNTP implementation).

I believe that this ends up producing a clean interface to time that can be fully implemented on the bigger ports using newlib and LwIP, and that can be stripped down, e.g. without time-zone support, for smaller ports. It somewhat side-steps the incompatibilities between RTC implementations by leaving that class along for legacy use, as well as for minimal ports without utime.

I volunteer to port this PR to the unix and stm32 ports so these are in-sync.