Проблема с получением времени time(nullptr)

Пытаюсь получить время из сети. Нашел такой код:

Код (C++):

#include <ESP8266WiFi.h>
#include <time.h>

const char* ssid = "";
const char* password = "";
int timezone = 3;
int dst = 0;

void setup() {
  Serial.begin(115200);
  Serial.setDebugOutput(true);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  Serial.println("\nConnecting to WiFi");
  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(1000);
  }
  configTime(timezone * 3600, dst * 0, "pool.ntp.org", "time.nist.gov");
  Serial.println("\nWaiting for time");
  while (!time(nullptr)) {
    Serial.print(".");
    delay(1000);
  }
  Serial.println("");
}

void loop() {
  time_t now = time(nullptr);
  Serial.println(ctime(&now));
  delay(1000);
}

Проблема такая - первые секунд 12-15 он выдает дату и время на 1970 год (Thu Jan 1 03:00:04 1970). А потом уже начинает выдавать реальную дату и время.
В чем тут может быть дело? На забугорном сайте нашел такую фразу:

Т.е. нужно время для инициализации? 12 секунд?
у меня ESP 12E

 

не совсем понял, в чем проблема - в том что первые 12 секунд время неправильное? - ну так подождите 15 секунд или просто не используйте время (не показывайте и тд) пока оно не установится

 

ну я это и хочу понять - это так и должно быть? просто во всех примерах про это не говорится, а в некоторых примерах время сразу показывается((

 

то, что время по сети получается не сразу - это совершенно нормально. У меня часики с обновлением времени по сети - могут минуту или две время грузить даже при хорошем коннекте.
а не говорится об этом - так это вроде очевидно должно быть

 

Чтобы было быстрее, необходимо выставить текущее время. ntp протокол сперва вычисляет дельту, затем выставляет время, затем опять вычисляет дельту. Если канал забит и дельта плавает, то синхронизация будет долгой. У меня распи при включении в тех же временных рамках получает время.

 

спасибо большое - успокоили меня) тогда буду с чистой совестью задержку в секунд 15 ставить и всё!

 

может подскажете - столкнулся с такой проблемой: при подключении к wifi с автоназначением ip адреса - синхронизация времени работает нормально. Если пытаюсь назначить статический ip:

Код (C++):

WiFi.config(ip, gateway, subnet);

то время не синхронизируется. Тут тоже какой-то подводный камень есть?

 

первое что приходит в голову - назначаемый IP не входит в подсеть роутера

 

Не ставьте задержку. Ставьте проверку на 1970 год. Если год изменился то...

 

Взывает сомнение данное объяснение ситуации. Сильное сомнение.
Правда заключается в анализе того, как действует подсистема запроса времени в составе того или иного конкретного устройства. Как часто осуществляется повтор обращения к серверу времени / очередному серверу времени после получения ошибки. Возможно первый запрос осуществляется еще до входа в сеть, после чего возникает внутренняя пауза. Затем вновь проверка.

Вычисления любого рода даже для восьмибитного контроллера человеческому разуму не заметны.

 

Нет. Скорее библиотека, что отвечает за работу со временем, имеет callback на получение ip-шника. Получен адрес - сработал callback. А если адрес установлен заранее - процесс получения отсутствует.

 

тогда лучше взять либу что-то типа NTPClient - там запрос времени выполняется явно. по команде, а не по каким-то непонятным условиям

 

Кратко про ntp по-русски.
https://www.mobatime.ru/index.php?option=com_content&task=view&id=318&Itemid=26

 

И там не сказано, что вычисления занимают какую-то существенную роль в этом процессе. Как и время движения пакетов.

 

Более того, библиотека что у ТС, может работать вообще по другому принципу. Например (не утверждаю), если отправить запрос на любой доступный сервер, то в заголовке ответа всегда есть время.

В общем, без анализа библиотеки здесь не обойтись. Но это - кому нужно



Безумие какое-то.

 

я про это и не заикался.

 

ключевое явление в этом вопросе - это то, что вся информация упакована в UDP пакет. А UDP пакет имеет одну особенность:

 

"Ты громко думал".

Он еще имеет сердце и душу.

Какие бы особенности пакет не имел, его обрабатывает МК по установленному алгоритму. В нем всегда и дело.

 

в данном случае всё определяется сроком жизни UDP пакета. В распи мозгов хоть отбавляй, но и она синхронизируется не так быстро.

 

Угу. Тот кто ее программирует - он не при чем. Она сама.