Once again, clocks will “spring forward” on Sunday, March 8. What does that mean for your application? If your software requires accurate time, then setting a clock is not sufficient. An NTP Server may be used to ensure that your time is accurate, but NTP does not utilize time zones. All times broadcast on NTP are broadcast in Coordinated Universal Time (UTC). If the application requires local time, then it must be aware of both time zones and daylight savings. In the standard C/C++ time library, time zones and daylight savings are described in two separate standards, Olson and POSIX.
Olson
Olson format utilizes a database that tracks each daylight savings change, be it by law, war, or even to reduce the mental strain on students studying for national exams. (A change that was reverted, but not before a rule was created to meet the change). Naturally, this database can get quite large. The North America database is well over 3000 lines, including meticulous comments on each change. This capability comes at a cost. Lookups must load and parse the database, which may lead to a performance penalty. Patches for the Olson database are released many times a year, as governments have a habit of modifying their time zone and daylight savings rules, often with little or no warning. The database is public-domain, and can be downloaded at IANA.org.
# Olson database for Luxembourg marking the switch to Central European
# Time (CET) after the Germans invaded in 1940
Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun
1:00 Lux CE%sT 1918 Nov 25
0:00 Lux WE%sT 1929 Oct 6 2:00s
0:00 Belgium WE%sT 1940 May 14 3:00
1:00 C-Eur WE%sT 1944 Sep 18 3:00
1:00 Belgium CE%sT 1977
1:00 EU CE%sTPosix
POSIX format takes a different approach to managing time zones and daylight savings. Instead of maintaining a historical database, POSIX format explicitly defines time zone and daylight savings rules in a single string. Historical lookups are not supported. This approach offers a performance advantage, increasing lookup speed. For example, the POSIX string describing Eastern Standard Time (EST) and Eastern Daylight Time (EDT) is EST5EDT4,M3.2.0/01:00:00,M11.1.0/02:00:00.
EST5is the timezone name and offset from UTCEDT4is the daylight savings timezone name and offset from UTC,Mstates how to parse the following. In this case, it will describe Month.Week.Day3.2.0is the start of EDT. It is the third month, second week, first day (Sunday)/01:00:00is the hour EDT starts,Mstates how to parse the following. In this case, it will describe Month.Week.Day11.1.0shows the end of EDT. Is is the eleventh month, first week, first day (Sunday)/02:00:00shows the hour EDT ends
Daylight savings time does not always follow the template of “spring forward” one hour in March and “falling back” one hour in November. In the southern hemisphere, if observed, daylight savings time begins in the fall, opposite of the northern hemisphere. A few unique cases can be examined in POSIX format.
Local Time and Your NetBurner
As always, our goal at NetBurner is to help you get your applications up and running without having to worry about the details and minutia of every system, standard, and protocol available. To help get local time requirements under control in your programs, we’ve provided a function, tzsetchar(), that can be used to set the local time on your module using a POSIX formatted string. Using it would look something like this:
tzsetchar("EST5EDT4,M3.2.0/01:00:00,M11.1.0/02:00:00");
You see this in action in our NTP client example (available with our NNDK), where we show how to get the time from an NTP server, and then display the UTC and local times to a serial port.
Conclusion
That about wraps up this article. We hope that it has shed some light on the sometimes confusing world of time zone formats. As always, we’d love to hear your thoughts, experiences, and concerns when it comes to time zones and building robust embedded applications. Please feel free to drop something in the comments below, or email us directly.