Time Zones and Daylight Savings: Getting it Right with Olson and POSIX

globe
Share on facebook
Share on reddit
Share on twitter
Share on linkedin
Share on email
Share on print

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.

Perfect Timing. Try Our ARM® Embedded Dev Kit Today.

Netburner ARM Cortex M7 embedded Development Kit for IoT product development and industrial automation.

Or, learn more about NetBurner IoT.

Old time sheet of railway times.
Figure: Railway time, an early prototype to universal timezones.

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%sT

Posix

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.

  • EST5 is the timezone name and offset from UTC
  • EDT4 is the daylight savings timezone name and offset from UTC
  • ,M states how to parse the following. In this case, it will describe Month.Week.Day
  • 3.2.0 is the start of EDT. It is the third month, second week, first day (Sunday)
  • /01:00:00 is the hour EDT starts
  • ,M states how to parse the following. In this case, it will describe Month.Week.Day
  • 11.1.0 shows the end of EDT. Is is the eleventh month, first week, first day (Sunday)
  • /02:00:00 shows 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.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on email

Subscribe to our Newsletter

Get monthly updates from our Learn Blog with the latest in IoT and Embedded technology news, trends, tutorial and best practices. Or just opt in for product change notifications.

Leave a Reply

Your email address will not be published. Required fields are marked *

Click to access the login or register cheese