Skip to main content

The Surprisingly Complicated Problem of Programming a World Clock

In computer science, there are a lot of things we would normally take for granted, but it might not be so easy to program. Take time, for instance. If we wanted to create an app to calculate how many seconds ago a time and date was, it seems straightforward. Of course we would account things like leap days, but as I discovered, it quickly becomes a lot more complicated than that.

As Tom Scott explains in an episode of the YouTube Channel, “Computerphile,” a simple-sounding app like this can be jarringly complicated. For starters, to create this app for a worldwide audience, it seems reasonable to make it available in all time zones.

To adjust it for each time zone seems straightforward enough. All you have to do is take the Greenwich Mean Time and add or subtract hours based on the time zone that the user is in, right? Not quite.

Take daylight savings time, for instance. It varies from country to country when daylight savings starts, and then there are some states/countries that don’t go on daylight savings time. This is just the tip of the iceberg of how complicated it gets.

There are times when countries skip days when they cross the international time zone. Countries can often switch time zones several times, even within the same year. Some countries can be in the same area but in separate time zones, such  as Israelis and Pakistanis. Historically, we haven’t alway been on the same calendar. Russia only switched to the Gregorian calendar in the twentieth century, complicating matters even more. There are even more confounding historical absurdities, such as the year used to start on the 25th of March, bizarrely.

There is even a such thing as leap second, but leap seconds don’t exist in astronomical time, and the differentiation is important because of how they manufacture telescopes and such.

This video revealed just how easy it is to take a problem and not realize how much more vastly complicated it can be and to appreciate the people who came before me and worked out this absurdly complicated problem.

I found it interesting because it was a problem I never thought about before. It seems like an easy enough problem until you find out how complicated it really is. Like I say, it is easy to take something like this for granted, and this makes me appreciate how seamlessly most technology that uses programmable clocks runs. Now that I can understand how vast and complicated the problem is, I can appreciate those who came before me and did the hard work to get it right.

https://www.youtube.com/watch?v=-5wpm-gesOY

Comments

Popular posts from this blog

Data Structures Primer

I've been a tutor for this past semester to students taking Introduction to Programming. Many who have come to my session are moving on to Data Structures next semester. They asked if they could have a primer as to what to expect. I have some resources that I have found helpful both while taking the course and tutoring it in the past. It will take me a little bit to compile a good list of those, but for now, here is a bare-bones list of topics of topics you might expect to see for a data structures course: Part 1: - Running time of code segments (Big-O Notation) - Abstract Data Type (ADT) - Interfaces (when to use "implements", cannot instantiate them, what inheritance is) - Superclass, subclass, method overriding/overloading - Abstract classes Part 2: - Binary Search Trees - Stacks (and its four methods — push, pop, peek, empty) - Linked list (single, double, circular) - Prefix and postfix notation (compare to infix) Part 3: - Min/Max Heap - Hash Table...

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.” I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse. The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left. This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would ass...