This is a cross-post from https://github.com/espressif/arduino-esp32/discussions/8653 as it didn't yield any results there.

I noticed that getLocalTime() is consistently taking 5-10+ seconds to complete. So far I haven't been able to find the root cause.

I am testing on a ESP32-WROVER-B module. On startup the device first connects to WiFi and then tries to sync time.

boolean initTime() {
  struct tm timeinfo;

  log_i("Synchronizing time.");
  // Connect to NTP server with 0 TZ offset, call setTimezone() later
  configTime(0, 0, "pool.ntp.org");
  // getLocalTime uses a default timeout of 5s -> the loop takes at most 3*5s to complete
  for (int i = 0; i < 3; i++) {
    if (getLocalTime(&timeinfo)) {
      log_i("UTC time: %s.", getCurrentTimestamp(SYSTEM_TIMESTAMP_FORMAT).c_str());
      return true;

  log_e("Failed to obtain time.");
  return false;
  10:12:28.118 > [  3634][I][connectivity.h:17] startWiFi(): ...done. IP:, WiFi RSSI: -55.
- 10:12:28.118 > [  3700][I][util.h:25] initTime(): Synchronizing time.
->10:12:34.025 > [ 11572][I][util.h:37] initTime(): UTC time: 2023-09-19 08:12:34.
  10:12:34.037 > [ 11572][I][util.h:60] setTimezone(): Setting timezone to 'CET-1CEST,M3.5.0,M10.5.0/3'.
  10:12:34.042 > [ 11574][I][main.cpp:175] syncTime(): Current local time: 2023-09-19 10:12:34

In the above example it took ~6s for a "valid" timestamp to become available.

  • 1) Have you tried a different NTP server? 2) Why is it important to synchronize your local clock in as few seconds as possible?
    – st2000
    Sep 23, 2023 at 22:16
  • Try replacing pool.ntp.org with (one of) its IP addresses eg.
    – Nick Gammon
    Sep 24, 2023 at 5:49
  • @st2000 I tried different servers but all by-name so far (i.e. implicitly using DNS). I want this to be done as quickly as possible as it's part of the setup() sequence. The sketch should only proceed with an accurately synced clock. Sep 24, 2023 at 18:42
  • @NickGammon thanks, didn't try that yet. Sep 24, 2023 at 18:44
  • it should connect to the server just once at boot, and then every so often, which is the 4th argument to the NTPClient constructor (the refresh time in ms). On the ESP32, every 15 mins is fine to keep well under 1s drift, which is the resolution of the interface anyway.
    – dandavis
    Sep 24, 2023 at 23:36

1 Answer 1


Based on the wording in the question, it appears you are requesting an NTP re-synchronizing event often. Perhaps as often as possible. Consider that most Arduino projects request an NTP re-synchronizing event once to set the local RTC. Then perhaps once a day to check if the RTC is accurate.

Keep in mind that many NTP servers defend them selves from attack by throttling the service from an IP address who utilize them excessively. This quote:

The NTP server may throttle traffic, especially for clients making frequent requests.

... is from this web site.

In case you are not aware, if time is important for your Arduino project, consider adding RTC hardware. This can be set to the the local time just after the NTP re-synchronizing. From that point forward, the local RTC can provide the time. Later, it may be prudent to check the local RTC against the NTP reported time. But this is usually not necessary for days at a time for the vast majority of Arduino projects.

  • That is a very plausible explanation, thanks! While working on a new sketch I go through the compile-upload-reboot loop (far to) often. Since my initTime() is triggered from setup(), requests from my IP address hit the NTP servers very frequently. I guess I should consider running my own NTP server (e.g. a cturra/ntp Docker container) and rewire my sketches to hit that one. Sep 24, 2023 at 20:35
  • 1
    Thanks. I am curious. If you do not make an NTP request for, say 24 hours. Do you see an improvement in NTP response time?
    – st2000
    Sep 24, 2023 at 23:07
  • Appears indeed to have been the root cause. Being away from sketch development for a couple of days solved it. Sep 30, 2023 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.