Aunty Beeb & odd dates

Almost exactly 51 weeks ago I was listening to BBC Radio 2 while going about my day. Nothing out of the ordinary there but apparently all manner of chaos was happening at BBC Radio's interactive department.

For those not familiar with daytime Radio 2, much is made of crowd-sourced content. That is the presenters actively encourage the listening public to call, text and email on a variety of topics. Of particular note here is traffic reports where UK road-users are asked to let them know of any problems so they can be relayed to the listening audience.

On that fateful day however only email and the phones were working. Why was this? Had the SMS relaying systems failed? Had the cellphone companies screwed something up? Were there unavoidable repairs or upgrades happening? Did someone forget to pay a bill? No. It was simply the fact that the days date was the 29th of February.

The software systems handling the text-messages, presumably responsible for routing them to the right studios just couldn't handle the unusual date.

I don't want to pick on The Beeb but this is a primary example of where proper system design would have prevented such problems.

Date and time arithmetic is tricky stuff primarily because it's all in such disparate bases. 60 minutes to the hour, 24 hours to the day, 7 days to the week. And even though we can be sure of 12 months, the number of days in those months is different for each month and in the case of February changes depending on the year!

When designing a system to handle dates it's an understandable decision to store the dates in some human-readable form such as 'Tuesday 17th February 2009'. While this is easy for us to read and understand, writing a program to understand it is a real nightmare.

Some clever folks strictly stick to numbers so it's easy for a system to make comparisons. The same date above could be expressed as 17022009, with tomorrow as 18022009. This appears to work fine as the second number is greater than the first, therefore it must be a later date. But what happens if have 21022008? This is a date from nearly a year ago, yet our simple comparison system would deem it to be in the future as it's the bigger number.

Even cleverer folks flip things around a bit and concatenate the numbers according to specificity. For example the same date above could be expressed as 20090217. Last years date would be 20080221. Perfect! Or is it? When we try any form of arithmetic on this date the system falls back on it's own native binary and transforms things in to decimal for us mere humans to understand. As people we understand that a month from today is 17th of March. But add 28 days (the total number of days in February) to 20090217 and we get 20090245, or the 45th of February.

So how do we, and how could the BBC, solve this situation? We give the system a set of rules to describe dates. We define how many months there are in a year, what they are called, how many days in each month. We describe the phenomena of a leap year being every four years. But how could the system know whether this year is a leap year? Whether tomorrow is a Monday or a Wednesday? What time of the day it is?

We do it by falling back on the simplest building block of our time and date system, the second. By thinking of an hour as 3600 we can easily perform arithmetic. We can count weeks between two dates by subtracting the earliest date (expressed in seconds) from the latest date (again expressed in seconds) and dividing the result by 604800.

This solves our arithmetic problems. The system can now apply the rules we have given it by doing all the calculations in decimal seconds then working with rules to tell us the date in a way we understand. The final problem is that this only gives us abstract time blocks. 'Thursday' means nothing without a year, a month, and a day.

For this we turn to the epoch. We set a date and work from there. In Unix for example this epoch started on January 1st 1970. So 1 second past midnight on that date is simply 1. 1am is simply 3600. By using this we can convert any date to arithmetic-friendly seconds by simply dividing the time that has elapsed since the start of our epoch by years, months, days and so on. Adding an extra 86400 seconds (one day) for each leap year that has occurred since.

I know I've made this all sound so simple and the reality of writing a program to do all this converting would be far more complicated but almost all modern languages include functions to do this stuff for us. PHP for example has mktime() and date(). Python has 'time' included in its standard library.

The point is that in order to future proof our software we as developers must think in terms of simplifying data thus making it more adaptable and not just throwing plain text in a database. If only the BBC had been thinking in terms of useful data and the simple logic when building their systems they would have had no trouble.