Michael's Project Blog

• Blog Actions

I spent quite a bit of time thinking through various implementations and the resulting user experience for DST time shifts. I don't like any of the options I've studied. The idea of shifting the scheduler time, skipping (spring forward) or duplicating (fall back) set points in the process, is a non-starter for me. I could write a bunch of complex code that would try to schedule all the otherwise skipped items and know not to duplicate set points, but that seems like a lot of testing, debugging, and places for code defects that I'll find a decade from now. I've settled on a solution that at its core comes down to this one design philosophy:

• Always operate the software in either UTC or local standard time; apply DST shifts when viewing or setting the schedule and clock

For the controller I plan to always operate it in local standard time because again testing and debugging the scheduler where local time and UTC can be +/- 12 hours seemed like way too much work. This also means that the controller does not need to be told the timezone or timezone offset. It only needs to be told about the DST offset (0 or some positive integer minutes). The user will always interact with the controller in local time (DST or ST). The controller will store and schedule set points in standard time. For the user this is all as one would expect except for one effect. The previously scheduled entries will shift an hour at the DST shift. This is no worse than a controller that doesn't accommodate DST at all and a big improvement when the user is trying to set the schedule.
For the web server I plan to always operate it in UTC. The user will need to set a timezone with offset from UTC and DST start /end data (all the timezone data for the Timezone.h library). That should be relatively easy with the web interface. Timezone information is needed regardless since the SNTP client only receives UTC and must be offset for local time. Handling DST shifts on the Web Server are trivial since there is no scheduling logic. Again the internals will all use UTC and will be offset to local time when interacting with the user.

Some fun facts I learned along the way:

• The DST begin and end points vary all over the world and have changed many times in history; even in recent history. The shift has not and is not always 60 minutes; even today at least one country (Australia) has a region using 30 minutes
• The ESP8266 internal SNTP client can be set for timezone and automatically adjust for DST; however the DST shift points are fixed to align with some undocumented region, making the capability practically useless