Once upon a time, time was, by and large, governed by the sun. Least ways it used to be, but then came the railways. Y’see the trouble was that time in those days, or at least our measurement of it, was typically read off the sundial in the town square. Since the angle of the sun varies with latitude this meant that while it might be 2pm in London, it may be 2.30 in Edinburgh.

This local variation didn’t really matter in a world where the fastest form of transport available ran on grass and sugar lumps, but in the age of steam trains and telegraph, it started causing problems. If a train was due in at 10:15, did that mean London time or Birmingham time? So, the rail companies started using GMT (then known as “railway time”).

Now, we live in a connected world. It is now possible to communicate anywhere in the world instantly, and oceans which once would have taken months to cross can be crossed in hours. Many of us work in teams which span continents and time zones. Age old local time issues persist; a meeting scheduled for 3pm… is that GMT, Local (currently BST) or someone else’s local time? Where exactly is the person who scheduled this meeting anyway? They’re based in San Francisco, but their calendar says they’re flying to Austin today… so is that PST or Central?

But at least you’re always talking about hourly intervals, right? Not really, what about India (GMT+5:30), or China (GMT+8 everywhere even though the country spans about 5 timezones). Oh, and what about daylight saving? Or the fact that not everyone can agree as to when the change should occur, if at all.

You get my point.

Can’t we all just get along?

In the computer world at least, there is some hope for standardisation. In the Internet connected world it is standard practice to set the computer’s system time (that is, the computer’s base clock) to GMT/UTC and then store local time as an offset from that.

This is because Unix (which historically much of the internet was built on) stores time as a timestamp defined as the number of seconds from 1/1/1970, and is always GMT. This is nice and unambiguous, and will work fine at least until 2038.

Having the base clock set to GMT/UTC by definition makes it at least possible, to convert between times, but this is far from being user friendly. As a user, this is not something I should be worrying about.

Option 1: Abolish timezones

Essentially do what the military has been doing for years and give all times in GMT/UTC/Zulu.

While this idea does have a certain appeal (to me at least, as I spend large portions of my life dealing with UNIX timestamps), given the level of international cooperation it would require, it would almost certainly never happen. Local time, with all its weird eccentricities is here to stay, least ways until some future despotic world government takes over.

Option 2: Make software do a better job (Hint: This option is the correct solution)

Computers need to do a better job of handling time on behalf of the user.

While some apps, for example Google Calendar, do an ok job, the interface always feels a little clunky. Google calendar in particular is really awkward when scheduling meetings with people in other timezones. Where exactly are my work colleagues? When would be a good time to schedule a meeting given that it should ideally fall somewhere in the work day for all of us?

When I see a date on a web page I should be able to hover over the date and have the browser (or whatever bit of software I’m using) tell me what time it is where I currently am, and my collaborators should be able to do the same. On the web, this should be straightforward with HTML5’s new semantic elements and the penchant for modern devices to come with some sort of geolocation hook.

When I am collaborating with others I should be able to see where they are, and what time it is there, whenever I need to do anything involving time. Crucially, all this should happen naturally and without the user having to worry about it.

If I were to say “Lets talk at 3:15pm”, I think it would be safe for the software to assume I meant 3.15 where I am at the moment, as this is generally how humans think. If my colleague in New York sees this the software should automatically tell them that by this I’m referring to 10:15am local time. Of course it gets a bit more complicated if I omit the AM/PM, but the software could reasonably assume that I’m more likely to schedule something for day time than night, although this assumption should probably trigger a warning of some sort to highlight the ambiguity.

The more detail I provide, the better the fix, so if I specify the timezone, then of course the software should use that (and all who view it can see this translated to their current local time).

It’s an interesting question how one should handle the fairly common situation where someone says something like “Lets meet at 3:15pm your time“. The software should probably pick this up, but if we’re currently talking to more than one person we’d need to retain an idea of context in order to make sense of it.

…and then there comes the problem of translating such pronouns into other languages. Ouch.

The point is, this is the kind of stuff software engineers should care about but nobody else should have to. Let’s do this better.