Provide epoch in milliseconds

[iogbole]

Additional context

Additional requests

• Provide epoch in milliseconds #79 (comment)
• Provide epoch in milliseconds #79 (comment)

[Majubs]

Any response to this? I would like to know as well.

[LPena10814]

I would also like to know if this is possible.

[MHotchin]

It wouldn't be possible without changing the data type returned by getEpochTime(). Right now the unix time is 1,575,693,824. Multiplying by 1000 will overflow the maximum value that an unsigned int can hold.

Even if you did change the data type, the simple synchronization code used will never be accurate to the millisecond level - the answer would be more precise, but it would not much be more accurate. So, there's really no point.

[WhymustIhaveaname]

Need not change the datatype. Just add another float _current_epoc_dec to record the decimal part of the current time from the Epoch.

I solved this in Pull Request #102. I add a new function named get_millis() which will return a float in [0,1000) recording the ms number of this second.

[fededim]

@WhymustIhaveaname It would be useful to add a new method called getEpochTimeMs which returns a uint64_t containing the number of ms since 1-1-1970 because having 2 different calls (one getEpochTime and the other get_millis) could generate some drift if the second between the 2 calls changes (e.g. getepochtime returns 13/05/2020 08:41:59(.999) and get_millis returns 000 (meaning 13/05/2020 08:42:00.000)

[WhymustIhaveaname]

@fededim Thanks for your suggestion. I will add this function if my PR gets merged. But for now, you can add this function manually yourself.

unsigned long NTPClient::getEpochTimeMs() const {
  return 1000*this->_timeOffset + // User offset
         1000*this->_currentEpoc + // Epoc returned by the NTP server
         (millis() - this->_lastUpdate + this->_current_epoc_dec*1000); // Time since last update
}

[fededim]

@WhymustIhaveaname Ok, thanks. The PR can't be merged because the Travis CI build fails. You have to fix the errors, see here.

[WhymustIhaveaname]

The Travis CI build fails because I add a new ntp_demo.ino into it. The examples in this lib are too old and they are not showing the full capability of this lib. This is the reason why I resist to delete the demo, even it leads to check failure.

[fededim]

The errors of the build are quite strange, they two functions actually exists...I try to contact the reviewer in order to fix the build.

[sylvanoMTL]

I confirm the program from @WhymustIhaveaname works well. Here is a screenshot of 2 esp32s flashed using his NTPClient.h and NTPclient.cpp and a loop running at 10ms. Button were release at the the nearly same time (witch is tricky to clear the consoles and press tiny buttons).

The main loop contain the following code:

void loop() {
  timeClient.update();
  Serial.print(timeClient.getFormattedTime());Serial.print(".");
    int ms = timeClient.get_millis();
    if(ms<10){
        Serial.print("00");Serial.println(ms);
    }
    else if(ms>=10 && ms<100){
        Serial.print("0");Serial.println(ms);
    }
    else{
      Serial.println(ms);
    }
  delay(10);
}