- 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.