Time for a change
By: Bob Dahlberg
Tags: Time, Timezone, Software Development, Devices, IoT

In 2021, Europe will remove daylight saving time (a.k.a. DST). There will be no switching between time zones twice a year like we’re used to. For example, in Europe, two timezones are CET (Central European Time) and CEST (Central European Summer Time) that represent the same location but during different periods of the year. After 2021 there will only be one and no more switching. The first attempt from EU to scrap DST was back in April 2019, but the member states wanted more than a popular vote and demanded more time for such a change.

An extra exciting part of this is that each member country has to decide whether they will stick to their “summertime” time zone or their “winter/normal time” time zone. It means that countries in the same geographical time zone might have time that differs for one hour. The member countries need to make their decision by April 2020, in just about three months at the time of writing.

This isn’t an issue for us humans to cope with, and according to a survey, over 80% of the EU citizens look forward to this change. But how does it affect our software? All non-connected digital clocks may try to be smart and perform daylight saving time adjustment themselves. We can expect a period where we will need to manually adjust the time twice a year when we didn’t use to.

I’m a bit curious about all the small bugs it will bring to the world. All software that displays time in the local time zone that is fully functional today can become buggy when the change comes. It probably has more hick-ups or problems in showing the time than the millennium shift did.

Let’s take Java, for example, since it’s a reasonably large language. It has classes to handle time zones for us (and since Java 8 a proper way of doing it as well). Java keeps up with the DST by having the information stored in a central database that is up to date. That database is replicated when updating the Java Runtime Environment (JRE). Developers can choose to update only the timezone database for local installations.

So for a modern connected platform such as Java, this works great. But what about all the platforms, embedded runtimes, and runtimes that aren’t updated regularly nor maintained? Those will continue living in a world where Europe has DST forever.

I know everything is connected these days, and I do agree that most things we can think of are, but are they managed? My grandma doesn’t update her phone often enough, and my girlfriends’ phone never manages to update to the correct time zone when we are on vacation. I hope that all smartphone companies have a solid plan for those who don’t update.

And then there are devices like washing machines, coffee machines, thermostats, water heaters, digital billboards, digital locks, that often are controllable by timers. Many of them can be connected to wifi, but I’m guessing very few are. And even if they are connected or can be connected, it’s not guaranteed that they will update correctly. I know for sure that my washing machine and dryer aren’t connected since I switched router at home.

Say you have a cleaning service coming to your house every month at a specific time, and your digital lock is programmed to open up for them during a time slot, and after the change, they arrive, and the door won’t open for the next hour. Or you have optimized your water heater to not be to active during the night, but just in time for your morning shower, the first time you hit that cold morning shower, you won’t be too happy with the developers behind it.

What might cause more critical problems are if big companies don’t update their environments. It’s quite often you see big companies lagging behind the latest versions of frameworks, languages, and environments due to their focus on stability. For them, time is of the essence! For example, stock trading with incorrect times recorded will probably cause a lot of frustration and discussions.

All in all, I believe in us, the developers, and that we can handle the transitions well. These changes happen seldom, but they do happen repeatedly. So if you’re building an application that displays the time or handles time in any case, please use libraries that take these changes into consideration so that you don’t have to. For Android developers, use Joda-Time or similar, and for developers using Java 8 or later, use the java.time package. And help your DevOps to remember to update all runtimes so that all new rules are in place before they are applied out in the real world.

For more reading on the timezone database used in many JVM implementations, here are a few links with a lot of information. The Wikipedia-link also shows an example of the database and how it stores all changes in rules since 1970.

- https://www.oracle.com/technetwork/java/javase/timezones-137583.html

- https://en.wikipedia.org/wiki/Tz_database

Thank you for your time!

→ Bob

And thank you Erik Hellman and Ann-Sofi Åhn for reviewing.