Setting the time on an RTC with an ESP8266 and an NTP server

@pugwash

THANKS!  Very interesting indeed.

@pugwash

Thats a very good idea indeed.  Duly noted and copied to my snippets files 😀.  Thanks for sharing.

ah! this is close to what i am trying to achieve in This Post. i will try and work out how to make this fit my project but i am very new to it all. Thanks for posting it!

@pugwash

How does the summertime adjust work.  I am on the east coast USA and time.gov says my offset is -4 hrs from UTC in April (EDST).  If I use -10800 for offset(3 hrs), and -3600 (1 hr) for summertime adjust, I get the proper time on clock.  Will this automatically correct in November?

@royz With any luck, we will be rid of the DST before next November as the US has finally passed the Federal enabling legislation. Now, it is up to the State and, in Canada, the Provincial authorities to make it happen. I know on the west coast that all the players, namely CA, OR, WA, and BC, have an interest in being on the same time due to cross-border trading, I assume equally so on the east coast, but that involves a great deal more players and politicians being what they are will need to be voted out until all players are agreeable. Just because the public wants something doesn't mean we get it, that would be a democracy, and neither country is that close to that lofty goal. In the meantime, seasonal adjustments are not universally supported by the RTC chips themselves. Some may have onboard logic to do that, but generally, it is up to the supporting libraries to do that, and you probably need to seed the library with either a reliable time server like NTP or a GPS source.

@pugwash

On reconsideration, Eastern US is -5 hrs vs GMT.  Therefore I believe I should use -18000 for time zone off set and +3600 for summer offset which will result in 4 hrs?  If DST is not made permanent, my clocks will hopefully correct if have to "fall back"?

@royz The more self-documenting way to do that is via 2 variables, one for Time Zone commonly named TMZ or perhaps UTC_Offset and another called DST. This way TMZ is tied to your longitude and normally does not change unless you are in a moving vehicle then a GPS will provide the correction, The DST is either 0 or +1 hour and is controlled by the date and location (lots of exceptions, though). To be absolutely accurate, you need to have a list of exceptions by geological location, some as small as a city, township, or entire Canadian Provinces like Saskatchewan or US states like AZ and HI, but with about 19 ready to change now.

I have not looked into it, but I will make a small wager the NTP protocol likely will fulfill your needs.