It appears that the code adjusts the actual epoch time offset value based on a timezone offset.
That isn't how timezones should work.
For example a time_t value is exactly the same everywhere on the planet at a given point in time.
i.e. you never adjust the time_t value; you calculate/adjust the local time broken down time values when doing the conversion to local time.
To do otherwise corrupts the time tokens and makes them useless for any sort of logging.
The best thing is to use the bundled in NTP support along with the standard time library functions that come with ESP platform. The time API functions are well defined and documented and have not changed since their creation around 50 years ago.
This will provide application API functions than can provide local time including automatic DST/summertime corrections as well as background NTP synchronizations to keep the system clock updated/accurate.
There can be cases where the built in time support functions can not be used but those tend to be for very specific reasons including but not limited to:
The wifi internet connection is not reliable so there is too much drift from lack of NTP synchronizations.
The device needs to work beyond 03:14:07 UTC on 19 January 2038
Since the ESP code currently uses 32 bit values, it suffers from the Y2K38 problem.
My recommendation is that the bundled standardized time functions that come with the ESP platform should be used unless there is some very specific/compelling reason that they cannot be used.
i.e. use the standard POSIX functions when possible vs use proprietary libraries and functions.
Not only that but the proprietary solutions don't track time properly and almost never offer automatic DST/summertime local time adjustments.
If blowing off the standard time function, for using the WIFI to connect to some sort of time service for doing things like setting an RTC there are more advanced ways to automatically do it using things like location based time services like worldtimeapi.org which can provide the local time information based on the geo location of the IP address associated with the device.
It is useful for some applications that intentionally choose to not track time properly but want to provide a simple local time automatically without needing any user input for timezone.
i.e. the clock can self set itself automatically to the proper local timezone.
I don't know what "NTP response was off by 3 seconds" means.
But the WiFi reliability I was referring was intended to mean the lack of service/connectivity. i.e. if there were conditions/situations where WiFi were not available for extended period of time.
Not any sort of timing delay from NTP responses which is due to something other than WiFi connectivity.
If there is an extended period of time (think days or weeks) with out WiFi connectivity then the system time can drift since it would be solely using timer interrupts driven from the ESPs boards oscillator which means that the time would only be as accurate as the ESP board's crystal/oscillator.
Whereas if WiFi were able to provide a connection to an NTP server, the system time could be syncd/updated/corrected by the periodic background NTP updates which eliminates the time drift.
I still don't understand your issue since the bundle time support functionality in the ESP platform can be told to use any NTP service provider, including the very same ones you are using in your test code.
With the bundled NTP support, the NTP requests and system time updates and time corrections happen in the background as needed to keep the system time accurately updated.
When I use the ESP bundled time APIs with an NTP server I don't see any time offset from or drift as compared to other devices like desktop computers, cell phones etc...
Yes there can often be a delay of several seconds between when a sketch initializes the NTP system before the first/initial update of the system time, but the APIs provide for a way to know when this or any other update to the system time occurs.
The ping time to pool.ntp.org for example ranges from 53ms to 3000ms (as measured and reported on the NodeMCU).
Ok, I see. You can have some large latencies.
But NTP should transparently adjust for that.
I haven't gone and looked at the NTP implementation in the ESP platform code, but assuming it is a full implementation, then the latency shouldn't matter.
What can trip it up is if the links are asymmetric (up and down speeds significantly different.) or there is extreme variation constantly happening such that the messages exchanging during an NTP exchange/update have significantly different transfer or rtt times.
Have you tried the bundled NTP code to see if it can deal with your latencies?