Summertime/DST in programming; Do’s and Dont’s

There has been some fantastic examples over the years of companies getting things wrong with Daylight Savings changes. Probably the most notorious has to be the iPhone and how for two consecutive years, Apple couldn’t get the time change to work properly.

Granted, the problem extended over two years because testing Daylight savings fixes are tricky, as recreating switches in Summertime are very difficult to re-create. The best and only time to test is actually on a DST leap forward or fall back day (primarily as most network appliances will refuse to operate with devices set to the wrong date making ‘out of DST season’ testing near impossible).

One of the applications I have worked on over the years was a Press Distribution platform. The platform utilised a .NET library that had been written in the days of .NET1 that managed time zones. Early versions of .NET were like Java, and lacked suitable date and time zone classes.  Our Data Architect on the project had some sentimental attachment to the library as well (perhaps he authored it).  For the few years I worked for the company I learned that they also had issues around DST time changes with press releases. So there was something wrong, and it got me curious to dive into the problem.

If you work with Java, the whole concept of Date and Time is a complete mess. Are you a Java dev? Leave a comment and share your experience – let me know what you do to handle date/time critical work. Which libraries do you prefer?  I haven’t yet come to a conclusion which of the many date-time-workaround libraries for Java that I prefer.

If however you work with .NET, all the issues with date and time were resolved in .NET2 and up. There’s now robust, reliable date/time libraries in .NET, which mean you should never have another issue with DST changes. So why was the project I was working on vulnerable? The distribution platform wasn’t a .NET1 project – it had been upgraded to keep up to date with the latest frameworks, and was .NET 3.5 at the time. The real issue was that our Architect couldn’t seem to grasp what I can only label as ‘temporal mechanics’. He had no understanding at all about date and time, and his solution for DST events was to run database scripts to correct the times stored for time-critical work in the database.

This was madness to me.  Over the years, I’d like to boast that I have mastered time itself. And what is my secret? Bloody well use UTC for everything. If you store, operate on and collect UTC you will almost never have an issue with dates and time. It doesn’t matter if your platform is in any part of the world and targeting just a local audience. Use UTC for calculations and storage. Then when you present the data to users, apply the correct timezone locale. Never ever store localised time, as you’re only inviting problems in the future.

In my personal projects, I prefer to store time as a Unix Timestamp (seconds since Midnight January 1st, 1970 UTC). As a Unix Timestamp is an 11 digit number, you can treat it like any other number so it makes it a heck of a lot easier to do time range queries on a database, is much easier to port between different programming languages than native objects, and conversion to localised timezones is easier. In commercial projects, I’ll always try and use UTC in whatever format I can. I personally try and avoid using native date/time objects as it can present issues when transferring data between frameworks/platforms.

If you need to do something like a calendar event where the time of something has to be the same both before and after DST change, then you record the time independently from the date, and do checks based on the seconds since midnight that day. If you store both as seconds and sum them together, you can easily work out when things are meant to be in a consistent fashion that will be safe from DST errors.

The Press Release distribution platform still had issues with DST up to the end of its life. I got to feel smug as my work on the project involved creating a Social Media distribution plugin for the platform, and instead of using the flawed timezone library I used modern .NET2+ datetime objects and centralised everything in UTC. My Social Media distributions never had timezone issues or needed manual correction.

I like to think that I am a master of dates and time.

Leave a Reply

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