ESP8266 Community Forum

- Sat Nov 19, 2016 3:20 pm #58392 Very interesting.
With regard to the first method, as I understand from your description it gives UTC.
You mention it requires "quite some calculation" to get the local time. That is definitely true.
if you are in the USA, which I presume you are due to yr interest in the USA DST, you may be say 6-9 hours behind UTC, now ofcourse you can subtract that from the hour string, but it is going to be harder when there is a change of day or month or year. I believe C has a function for that, have to dive in to that. I think the "Time" library for Arduino has a function for that

Therefore the Time.is indeed might be easier. As I am not programming in LUA, I will need to write my own script, but at least now I know about the existence of Time.is. ... but maybe I will just use it once a day, due to their terms of use.
Thanks for that

- Sun Nov 20, 2016 12:57 am #58409 Another option: Time sync with Google : I've just remembered that I have done it a while ago and it was working quite nice to check my RTC time sync with it.

More details and code here: RTC and TIME sync with Google

Happy breadboarding,
TJ.

ESP8266 MPDMv4 AC MAINS Dimmer Home: http://esp8266-projects.com/2016/04/mpdmv4-mains-dimmerswitch-html/
Available on Tindie: https://www.tindie.com/products/nEXT_EVO1/universal-ac-mains-dimmer-mpdmv41/

- Sun Nov 20, 2016 10:22 am #58423 Sorry to join the party late
Not sure if it's relevant here, I don't use lua...
I have a device which functions as a web server & it get's time sync from a connected browser using javascript.

Ian

- Mon Nov 21, 2016 2:58 pm #58484 My NodeMCU project is a web-enabled smart clock, so I have encountered all of the mentioned time issues and more.

In short, I am using Method 1 in the 1st post only for an initial (on boot) determination of DST.

After that, I use a simple sntp.sync() to actually set the time.

As mentioned, you cannot add timezone to the hour. I add the Timezone (GMT Offset, actually -- they are different) *3600 to the raw unix epoc.

Yes, I do have to "do a little arithmetic". Not only is there Timezone, but there is the change from DST to Standard time twice a year. I implemented this with 2 Lua tables with US Spring Forward/Fall Back dates through 2029.

Obviously, my code only works for US DST. It would need to be changed for the other countries that use the concept of DST.

Other issues:

12/24 hour time, and issues like 12 hour time not having the concept of 00 hundred hours. I used modulo 12 to convert the hour, but I needed an additional line specifically to implement the concept of 12AM.

Day of the Week. This is another reason why you have to add Zone offset to the unix epoc before you call rtctime.epoch2cal().

I also learned that for 2 hours a day, there are 2 timezones in the pacific that are actually a day ahead. By adding the TZ earlier, my code should work even on an island in the middle of the pacific.

Even with all this, my code will not work for areas that have a 1/2 hour time offset and/or other DST dates (Iran being an example of both).

Implementing a clock that truly worked everyplace would require downloading and reading the IANA time zone database files, but that was beyond the available memory and computational power (I'm referring to the developer's memory and computational power, not NodeMCU).

I wonder how many IoT devices out there don't account for all these things.

I'm not going to share the full code here, as it is a complete project, not an example, but once it gets a little more mature, I will be open-sourcing the entire project.