Everything is more complicated than you think #1: Dates

Everything is more complicated than you think #1: Dates

Everything is more complicated than you think… everything. It is only when we sit down and really think deeply about something that we see the complexity, but it’s there. One of the reasons I have always found software development so interesting is because as engineers we need to design software systems based on real world objects and systems. In doing so we are forced to scratch beneath the surface of everyday things that we often take for granted and confront the complexities that await.

For example, to create 3D graphics we need a deep understanding of how the human eye works, how light interacts with objects and how to precisely describe a 3D environment using only numbers (ie. geometry).

To allow our computers to play audio we need to understand how sound waves work and how the human ear actually perceives sound. If we are writing software for a bank we need to understand how compound interest works, otherwise how else would we create the tools that bankers need to calculate how much money you owe them?

More personally, I've worked in the travel industry and needed to learn how airlines and hotels run. When it comes to software, even something seemingly simple, like a hotel reservation, has hidden complexity. If you book a night in a hotel you will need to provide a date, but have you ever actually sat down and thought about the concept of dates, or time, in general?

One thing that most software engineers will agree on is that working with dates and times can be surprisingly difficult. We all learn to tell the time at a pretty young age. It’s simple right? Two hands on the clock, one tells us the hour and the other tells us the minutes relative to that hour. It’s even easier on a digital clock, we just read the numbers. However, if we scratch beneath the surface we quickly realize that building systems reliant on dates and time is actually a lot more complicated than you think.


On the first of November 2010 thousands of people in the UK and Ireland showed up late for work. One hour late to be precise. The reason for this was a bug in Apple’s iPhone 4. The clocks are put back an hour on October 31st for daylight savings, which the iPhone accounted for by correctly adjusted the time displayed on the device. However the alarm application on the phone did not account for this, meaning that anyone using the iPhone 4 as an alarm was woken an hour later than expected. In this situation it is very easy to berate Apple for messing up something so simple, I mean the clocks change twice a year, how hard could it be? But if we look at dates a little closer it might just help us sympathize with Apple engineers that let this bug slip by.

Lets try a few mental exercises to get an idea of what I’m talking about. Firstly, what day does this date represent: 02/04/17? Depending on where you are from you might be thinking either the 2nd of April 2017 or the 4th of February 2017. Or is it 1917? Or just the year 17CE? Already some complexity is starting to emerge and we haven't even done anything yet. We're just trying to write the date down...

Thankfully we have established a standard format for the way we record dates, so we don’t have to deal with these issues too much. Generally we will use something called UTC, or Coordinated Universal Time, when tracking dates and times, and it looks like this:

YYYY-MM-DDThh:mm:ssTZD (eg. 2017-07-16T19:20:30+01:00)

The four Y’s represent the year. This means that when we write the date according to this format the year should consist of four numbers. The two M’s represent the month (the minimum value being 01, maximum  being 12) and two D’s represent the day (the minimum value being 01, maximum being 31). The ‘T’ denotes time, with ‘h’, ‘m’ and ‘s’ representing hours, minutes and seconds respectively. The ‘TZD’ at the end tells us the time zone.

With everyone using this format, computers can talk to each other and understand exactly what date and time are being referred to. And that’s it. First problem solved. We can now write down a date, give it to someone else and know that they will understand exactly what day it refers to.

But what if we want to do some more fancy stuff with dates. Let’s say we want to calculate what the date will be five days from now. We could simply take today’s date and add five days, but that will cause some serious problems. Let’s start with the date:


The 27th of January, 2017. Now if we simply add five days on to that date we end up on the 32nd of January, which just feels wrong to even say. It does not feel wrong to a computer though, to a computer they are just numbers stored in its memory. Software engineers need to account for this manually when writing software. First we need to know how many days are in January: 31. We need to add as many days as we can to our original date, but not go beyond 31. So of the five days we want to add to our date, the first four are still in January. We then have a remainder of one, which needs to be carried over into February.  So finally we end up with:


There are even more potential issues depending on the date we are working with. Don’t forget that there is no standard length for a month, so what works for January won’t necessarily work for other months. What if we wanted to add five days to this date:


Now we need to recognize that February only has twenty eight days and take that into account, but we also need to know if it is a leap year, as that will change our result by one day. Depending on the year the result will be eith

    2017-03-03 or 2017-03-02

At the time of writing this, 2016 was the last leap year and hence 2020 will be the next, but we have to remember that to a computer these are just numbers. As humans we attach significance to them and interpret them in different ways. If we want to teach a computer to do this we have to think of all of the little quirks that we generally don’t think of in our day to day lives.

So far we have settled on a format for our dates and understand the logic and rules behind working with them, however, as a globally connected species, things become yet more complicated. What about time zones and daylight savings time. Thankfully our UTC format takes care of time zones and daylight savings. The format itself does not change, we just need to adjust some of the values in order to translate it into a different time zone or daylight savings time. Take this date for example:


The “+01:00” at the end means that this represents a time that is one hour ahead of GMT. Basically GMT is considered the ‘correct’ time, and every other time is just an offset. New York would be “-05:00” because it is five hours behind GMT. Sydney, Australia would be “+11:00” as it is eleven hours ahead of GMT.

If this is confusing don’t worry about it - that is good as it illustrates my point perfectly, there is more to telling the time than meets the eye. It basically means that engineers have to translate UTC dates to local time when displaying them to users. As I am writing this it is 6:07am, which is GMT+1. However with UTC we would actually say it is 5:07 am (which funnily enough my computer currently displaying , presumably due to Windows forgetting either my time zone or daylight savings settings). So it is obviously important to account for that.


When I worked on airline software it was critical that we translated the UTC time to local time. You wouldn’t want to receive an email from an airline system with flight times in UTC as you could potentially arrive hours too early, or hours too late for that flight. So if you enter a date into a website or application you can safely assume that it is converted from your local time into UTC and stored like that, rather than the format you actually entered. That same system will convert it back to your local time when displaying it to you.

Unless you're and engineer there is a good chance you've never thought this deeply about dates. And this likely extends well beyond dates. Have you ever though really deeply about things like how to set up traffic lights so that the city isn't hit by total gridlock? How public transport schedules are set up? How your phone can tell you how far away the nearest Starbucks is?

This is something I want to explore more. In what clever and creative ways do we (ie. Humans) take complexity and hide it behind systems so that the general population can go about their days blissfully unaware of how things work behind the scenes.

Do we need to rethink how we deal with offensive language?

Do we need to rethink how we deal with offensive language?

5 ways to get fat, unhealthy and die young

5 ways to get fat, unhealthy and die young