Daylight savings transition tonight

Tonight daylight savings starts here.

You may say "wait but daylight savings is not starting or ending where I am" and you might be right from a local perspective, but any time you have interactions with somewhere else that does have a daylight savings change you have to deal with the fact you are now a different amount of hours away from them. Unless accounted for someone can now be off by an hour (or half an hour or two hours).

There's a lot of things that are inconvenient about daylight savings transitions, such as disruptions to sleeping patterns, changes to schedules to match people from outside your time zone and handling all this properly in the systems you use.

Moving your "clocks" forwards or backwards is these days is not the worst part of daylight savings, many systems are timezone aware and will update the local time accordingly.

However some systems will make bad assumptions about local time and won't work properly (yes unfortunately when people attempt to write their own time related code a lot of potential obscure bugs like this inevitably come up in edge case situations). Further than this there's a lot of software systems such as Network Time Protocol (NTP) that will find out exactly what the time is. The accuracy with which NTP works is quite amazing, in your system there's a component known as a clock chip that will keep track of what the time is. The main way in which these chips work is that they using something like the speed at which a quartz chip will oscillate and use those oscillations to increment a counter. There's a whole lot of detail here, something I can cover in another post.

Keeping coordinated with people outside your timezone, is potentially one of the biggest annoyances with daylight savings, other people don't set their clocks forward or backward and since these clock transitions tend to be very much a local affair it will likely not be front of mind. From the perspective of software keeping coordinated with people from outside your timezone offset includes the local people from before daylight savings changes.

Will your system handle this transition properly?

Over my career I've seen many systems that were supposed to handle the notion of time be defective, either from believing falsehoods or have attempted to simplifying what is inherently a complex problem into something that is simple but incorrect.

There's a lot of interesting properties about time that you need to think about if you want to represent it properly. At a basic level you have a continuous property that you have to turn into something discrete. How computing technology does this is both fascinating and worthy of it's own post. Then there's all sorts of things like how if you move really fast time slows relative to other observers and real world systems such as GPS actually have to deal with since the satellites move faster than the people on the ground. While all these considerations about time are complex they don't change, light still travels at the same speed each year, the vibration of atoms in atomic clocks stays the same, and so on.

Daylight savings is a very political topic and like other political topics is subject to changes over time. And sometimes these changes occur without much notice. Times are important in the way in which they allow people to coordinate, it matters to me that I'm able plan to meet or plan to talk to someone at a certain time. Given that I do a lot of interstate business this means that I want to be able to pick up the phone and call someone when they are able to pick up the phone. It matters that we are both at that same time ready to talk even if our wall clocks have different times displayed on them.

So in order to correctly be in sync we must take into account what makes the wall clock time different in our different locations. So the only way to consistently get the localization of times right and to properly future proof and coordination tasks that involve wall-clock time we have to be able to keep track of everything that changes this wall clock time. To do this we must store some form of a database that will keep track of how time zones change and then make systems that correctly use this data. The IANA timezone database is one such database that contains this information.

How can I deal with all this?

The main idea is that everyone has to have some base time with which they can all agree on and then to convert this time to their local time. UTC is a very good choice for a base time since it doesn't have any annoyances like Daylight savings and is close to a monotonic time (leap seconds cause some issues] and there's proposals like UTC-SLS to modify UTC in such a way that leap seconds can be handled and monotonicity can be retained without having to add a lot of complexity into code that requires monotonicity to be correct).

The secret here is to architect your systems to be properly able to handle time and to use the right tooling. If you try to do it yourself you'll likely waste a lot of time and make a lot of mistakes. Timezones are just complex, but since they are incredibly important to our communities and to commerce much effort has gone into the technology that deals with timezones. Unless you are trying to educate yourself on this topic this is very much a wheel that's not worth reinventing.

I had often thought "wouldn't it be great to have a utility that helps me know exactly what the time will be in other parts of the world and handles all that timezone stuff for me?" I never had enough pain to actually have to seriously consider this until I started running an internationally connected business, at which point it became a serious pain point. Timezone aware calendars shared across your team are helpful for sure, but sometimes you'll just be on the phone with someone and they are ask "can you meet with me the same time of the day next week?" and I wanted to be able to within 3 seconds find the answer to this question in order to see what time that would be on my local time so I can make decisions about reserving the time for that client in my calendar. If I have to think about the daylight savings transitions and things like "are you +3 hours or +2 hours" is already longer than 3 seconds and it's a massive cognitive distraction for the client too, we are on the phone to solve our business needs, not to discuss the details of timezones.

Eventually I just had enough so I'm working on making my own small utility that lets me find out what time it is without breaking my workflow (which for me means a small command line interface that I can very quickly type what time I want to find and that gives me the results for the places of interest I have). While this is very much a work in progress the source code for this can be found on my GitHub. This project follows the advice above and attempts to use existing tooling to do all of the timezone logic.

Want help with timezones in your project?

Code that handles time properly is hard! One of the biggest pain points with timezones is that things you didn't know you didn't know can break your systems. It's worth finding someone who does have expertise with timezones to ask questions of so you can make sure you handle all of the nasty edge cases properly.

If you are interested in getting some help about this feel free to add me on LinkedIn and mention that you found me via this article and I'd be happy to talk about your needs.