Daylight Savings Time is becoming more and more of a controversial subject as civilization continues to integrate with roads, cars, and internet. The old ways of saving extra light by pushing the clocks around is becoming more of a frustrating tradition and less of something that seems useful to new generations—but aside from making extra busywork around this time of year, it also poses problems (and creates bugs) for developers.

How to deal with time

When programming time can become a massive problem when dealing with clients across the globe (or even just across the United States), in the usual developer parlance this falls under localization. For a good primer, this question posted to Stack Exchange is a very good start for some best-practices in general.

• Store all times in a unified standardized format not affected by DST—either GMT or UTC;
• When storing localization information always store time zones with offset intact and full time zone name;
• Always localize (convert to local time for client) at the last possible moment;
• Remember not all time zones are whole integers (for example, Indian Standard Time is UTC+5:30);
• Use NTP services on all servers and maintain clock synchronicity between all servers.

Time by programming language

If using Java, use Joda Time, a quality replacement for the Java date and time classes. It is designed to be better, smarter, and more extensible than the usual functionality in Java and includes a solid calendaring system. To the benefit of time-frazzled developers this library also includes up-to-date Time Zone calculations based on the public tz database. Joda Time updates the database with each new version and making manual changes to the configuration is easy.

If using .NET, consider using Noda Time. It is a highly well developed .NET API for dealing with time systems that stores in a unified consistent manner and enables quick localization and conversion using TZDB. According to the documentation the TZDB is embedded into the Noda Time distribution, but can be easily updated manually.

If using Perl, use DateTime. This library allows for the creation and handing of ambiguous times (due to the effects of DST), but it would seem the best practice would still be to store everything in UTC and use set_time_zone() to handle offsets and changes at localization time.

If using Python, use pytz. This library embeds the Olson tz database, enabling a calendaring system that easily translates between local times and a global time (UTC or GMT) providing accurate time calculations for Python 2.4 and higher. It is also designed to handle ambiguous times caused by the switch over of DST.

PHP 5.2 and above is easy, use the native time zones conversions provided by DateTime, and DateTimeZone classes. These versions of PHP are already mapped against the Olson db; however, its not updated as frequently as might be necessary. Keeping PHP up-to-date can be easy as updating the timzonedb PECL package at PHP.net.

If using Ruby, TZInfo provides a fairly good library for datetime timezone conversions using the Olson tz database.

Avoid these traps

Do not use JavaScript for datetime calculations unless you absolutely must. You never know what might be going on in the JS brain inside the browser—it’s best to have all that figured out server side before it is displayed to the client anyway.

The client datetime cannot be trusted! In all cases use the server datetime to update and inform the client because the client could be incorrect. When it comes time to localize outgoing, this can be done on server or on the client, as long as the server/client is aware of what timezone the client claims it is in.

Never compare client datetimes with server datetimes. Keep all the comparison and processing in the same space (the server) and the client should act as the interface to the user. In the case of mobile devices a client certainly could localize from server datetime for display; but the simpler the process the better.

Dealing with historical time?

Another problem might arise when it comes to attempting to discern proper time in the past—especially in the United States. For example, in 1967 US DST effects on time zones were standardized and changed previous time behaviors; fortunately, it’s unlikely for any application to care about exact local time before 1967. In 2007, however, recent enough to show up in a datetime calendar in some applications the DST window was expanded by Congress meaning DST existed during different days for certain states before and after 2007.

As a result, special considerations must be made when developing an application attempting to localize historical times. Fortunately, this is usually handled by a calendaring system (most of which are handled by the above APIs.) However, it may still be up to the developer to attempt to convert to one of these ambiguous or invalid times—or detect them—when a client attempts to input or access one of them.

Join in the discussion

Stack Overflow is an excellent resource for developers looking to peers for best practices and much of this information is garnered from a discussion of dealing with Daylight Savings Time and development. If you have a solution, add your two cents and catch up on what others are saying.