Is your code ready for summer time?

This weekend in the UK, the clocks jump forward. For developers, this is more than a lost hour of sleep. It’s a test of how our code handles shifts in timezones.

On Sunday, clocks go forward an hour at 1am. In other words, we go from 00:59 to 02:00.

It’s easy for us to write code for the ‘now’ and forget that twice a year we shift timezones. This often trips people up, especially early in their careers. Sometimes, the consequences of this oversight can lead to big headaches the day after the clocks have changed.

What things do you need to check ahead of the switch to summer time at the end of this week? Here are some suggestions.

Scheduled jobs

If you have automated jobs scheduled, do these fall within the skipped hour? What will happen when these fail to run? Similarly, when we fall back to GMT in the autumn, what happens if these jobs run twice?

Third-party integrations

If your code talks to remote APIs, are assumptions made about the timezones in the two systems? If the API uses UTC, but you’re passing local times, then you could be an hour different for the duration of summer time. This is unlikely to be the desired situation.

Displayed dates

Regardless of which timezone you store datetimes in your database (it probably wants to be UTC), your users will most likely expect to see dates and times in their local time. If a customer orders something on an ecommerce store at 11pm next week, what weekday will their account show for when the order was placed?

Are you ready for British Summer Time?

The lost hour of sleep this weekend is unavoidable, but bugs in code relating to the shift don’t have to be.