However, instead of waxing philosophical about time as a concept, I have always wanted to write about the problem with our human valuation of time, especially how it affects the computers we use daily. I was inspired last year to write down my problems after I spent a dreadful 3 months fixing various bugs with one of my apps, Eduplanner, which is in essence an event scheduler. Time (the dimension, not the magazine) was the cause of all these bugs.
Readers old enough may remember the scare of the Y2K bug. There were even TV shows and songs about it. This problem arose due to the way computers stored time prior to the year 1999.
Apple, the company, has faced several issues with the software on their iPhones; from alarm clocks going off one-hour late every New Year to the system clock on the devices displaying time one hour behind after daylight savings time change. Even Google has not been exempt from the issues of time. The Android OS once had a bug that omitted "December" from the calendar app, likely due to some zero-indexing error. There are multiple articles across the web discussing how developers should handle time and historical dates.
The world, according to most computers will end at 03:14:08 UTC on 19 January 2038. Why would this happen? The reason is simple enough: time would end, or would be reset, for most computers at this time. In fact, most mobile phones that exist* at the time of this writing will stop working or bug out severely immediately the clock strikes this time, no matter how well you maintain them now. Without going into too much detail, humans have identified this problem as the Year 2038 problem.
Yes, truly, time is a real issue when dealing with computers. I discovered that for myself in 2013. When starting the development of Eduplanner, I made many naïve assumptions. Disregarding the complex, but relatively smaller, issues I faced when trying to store a timeline of events that were static, but potentially infinitely recurring, I assumed I could treat time as a straight line. I was wise enough to recognize that I would have to deal with time zones, but I assumed every user of my app would be on a fixed point in the timeline, a point that is of a fixed interval away from every other user. Boy, was I wrong!
My first problem began when I started receiving crash reports from users who were located in Europe. The app crashed when they attempted to save events without an end date.
"Why can't I reproduce this crash," I fumed for weeks.
I tried to fix this in multiple ways, before correlating the crashes with users in a particular region, Europe. I then had the bright idea to change my system clock's time zone. This resulted in an immediate, unapologetic software crash.
Why did the software crash just because it thinks I'm in Europe? Well, without getting too technical**, this issue was caused because the computer was trying to compute a point in time before 00:00:00, January 1, 0001. Well, why was it trying to do that? Because the event we were trying to save in the app had no end date, I had made the app store the value for end date as 00:00:00, January 1, 0001 in local time to signify "no time set". This time is the minimum value of time that Microsoft computers can recognize. When trying to read that value, the computer attempted to convert this value to Coordinated Universal Time (UTC). Of course, if your local time were ahead of UTC, as most people in Europe and Asia are, the system would attempt to go back beyond this minimum time that it recognized and crash. Hard! According to Microsoft computers, nothing existed before the year 1 BC.
This was just one of the numerous issues I faced while developing Eduplanner. I wish I could say I've fixed all time related bugs in Eduplanner, but that would be a poor lie. Granted, I should blame myself for not carrying out proper testing on the app using different time zones, simulating daylight savings and simulating user migration between multiple time zones, but the inherent problem is with most people's assumption about the concept of time. This is a problem that lies dormant within all programmers who are yet to deal with time in software, a problem waiting to pounce and deliver misery upon the poor soul. I won't attempt to bore anyone any longer, but I should leave any adventurous developer with this warning: "Beware of time zones. Therein lies madness"
Brilliant video from Youtube channel ComputerPhile describing the madness of time zones
* With the possible exceptions of the newest iPhone 5S and all Windows Phones
** For the technical amongst us, the issue I faced is better explained here
