A Solution to the Timezone Conversion Problem in Software Development

Anyone who has ever had to write code dealing with timezones and the conversations thereof knows what an impossible mess things become. I am writing some Python code in which I am taking dates/times in UTC and converting them to local time. This sounds like a simple matter of adding or subtracting a certain number of hours from the UTC time. A line of code should take care of it. I have yet to see a single line of code that can perform this operation. StackOverflow has hundreds of posts on this issue, each one more complicated than the last. But after lots and lots of thought, I have come up with a solution that makes the whole problem obsolete.

My solution is simple. Do away with timezones entirely. Make Greenwich Mean Time the standard across the globe. When it is noon in London, it is noon everywhere. That might sound silly, but the fact that I got to bed at 9 pm and wake up at 5 am are completely arbitrary. I got to bed when I feel tired. Often that is when it is dark out. I tend to wake up before the sun rises. So what if that time happens to be called 2 am – 10 am. I am an early lunch-eater. I generally eat around 11 am. In GMT, where I live, that’s 4 pm. So what if I call that time 4 pm when the sun hasn’t even reached its zenith yet?

It makes scheduling meetings easier, too. I do a lot of meeting scheduling because many of the people I work with are in California, which is 3 time zones behind Virginia. I am constantly doing math in my head: “Let’s see, if the meeting is 3 pm here that’s 6 pm in Santa Monica, right? No! Other way around. It’s noon in Santa Monica. Darn it! Everyone will be at lunch!”

It wold be much easier just to say that meeting will be at 3 pm. The sun will be a further west in the sky here at 3 pm than it will be at 3 pm in Santa Monica. But so what? The sun is higher in the sky in Bogotá, Colombia than it is in Arlington, Virginia at noon today, and both cities are in the same timezone.

And while we are at it, let’s just get rid of Daylight Saving Time. It adds a nasty wrinkle to the time conversions that make things more complicated than irregular verbs in an English grammar. Besides, Daylight Saving Time no longer matters when everyone is in the same timezone. There will be people heading to work at 11:30 pm just as the sun is starting to rise. Will altering that time to 12:30 am make a difference under those circumstances?

Sure, it will require some amount of adjustment. A lot of computer programs will have to be rewritten, and I can only imagine the havoc such a change would create for things like airline schedules. But certainly it is worth it for the entire world to change just so that we programmers no longer have to deal with the complicated mess that is timezone conversations.

Don’t you agree?

3 thoughts on “A Solution to the Timezone Conversion Problem in Software Development

  1. GMT – or UTC? Some countries (heyas, UK) use GMT most of the year, but not all (coming back to the DST problem, of course). Personally, 90% of my life is in UTC, but then, that’s what I get trying to keep uniformity in a digitial universe. That other 10% of course marks my interactions with real humans, so I’m all for this if for no other reason than I can stop converting back and forth.

  2. I thought Earth should have adopted this policy back when I was in the Navy – 27 years ago! Then again, humans often do things that go against common sense.

  3. hmm. instead of doing math, we’d have to remember that the people we work with (mine are in Portland) eat lunch at 7pm instead of 4pm, which I’m not sure would be any easier.

    Step one would be to get rid of DST, for sure. Step 2 would be to have the USA go to two time zones – east and west – to follow the TV satellites feeds.