If one is a programmer, then dealing with time zones is going to be indispensable. There is little to offer in terms of advice here. But a cautionary tale will serve us well.
Now, if a programmer can find his way around, he should never deal with time zones!
Suppose that a programmer comes up with an application for calculating how many seconds something is in the past. On typing in a date and time; the application is going to provide you with the number of seconds that have lapsed. There is no reason why the application users won’t be delighted with the app.
In the application, we can add a little box that lets us change the time zone.
Now consider that we intend to figure out the time lapse between now in New York and five days ago in London. This should be all fine. No problems. We are, here, assuming that the programmer has included the time zones in the US and the UK in his app. There’s also going to be a tiny drop-down menu, which allows one to change what hour backward or forward of Greenwich one is.
With time, this app will become popular. So, people from outside the UK and the US will also begin to download it. One by one, people from all nations will begin to contact the app developer to make special cases for them.
A caller from Australia will call the developer to tell him that they are 9½ hours ahead of Greenwich. The developers, in turn, will make provision for Australian users to use the app. Similarly, someone from the Kingdom of Nepal may also call the developer to share that they’re 5¼ hours ahead of Greenwich. A special case will be made for them as well.
At this point, the developer will realize that he should be looking into all the time zones that exist worldwide. In all likelihood, this is exactly what he’ll be doing.
The story, somehow, does not end here
Autumn will then arrive in England. An Englishman is likely to call the developer and share with him that in England, they’re an hour out at the time. The developer, located in the US, we’re assuming, will be taken by surprise. He’ll communicate that he has made a note of when daylight savings changes for the US, and has already made changes to the app accordingly.
The Englishman can then tell the developer that daylight savings change a week earlier for England. They shift their clocks back a week before the US does.
This is getting fishy, the developer now realizes!
So, the developer makes provision for daylight saving time for each country in his app.
Someone from the southern hemisphere now calls the developer and tells him that they’re not shifting back in autumn. They shift forward. Their spring…is in November. The developer can now code that line also.
The peculiar case of Samoa
A Samoa citizen is now likely to call the developer, from far ahead in the Pacific. Samoa skipped a day the other year, the caller tells the developer. The developer is surprised as can be.
It was in 2011 that Samoa got directly to December 31st from December 29th. The nation shifted from one side of the international date line from being hours and hours behind Greenwich to be hours and hours ahead of Greenwich. This lets them trade better with Australia.
The developer now understands; he’d have to make a special case for Samoa in his app. This takes account of the one skipped day in Samoa’s calendar.
It is interesting to note that Samoa’s case is not one of a kind. Such occurrences have taken place in the past as well, and the developer can make provision for them all.
It is, then, noteworthy that the nations all announce such changes in advance. An anecdote is worth mentioning here.
When World War II took place, the English used to have double British Summer Time. It went completely onto BST and then just added an extra hour. So, it was two hours ahead of Greenwich. This, surprisingly, was despite Greenwich being in England.
The developer will feel that he can make a provision for this as well in his app.
So, the developer feels that all he has to do to be on track with time zones is to subscribe to the list of when countries are going to change their time zones. Now, this happens all the time. It may happen several times in a year because governments change over.
Libya time zone story
In 2013, with only a couple of days’ notice, Libya decided they weren’t going to put the clocks back. This was with enough notice that no one could get the update out in time. So, every Libyan computer, no matter what operating system it ran, was an hour out.
When the developer heard of the development, he quickly made the relevant changes to his app.
Israeli and Palestinian time zones
Someone from the West Bank now calls the developer. On the West Bank Israeli population is in a different time zone from the Palestinian population because one is following Israel and one isn’t.
So, we have two populations of people in the same location who are following different time zones. And now, they all need to ask themselves whether they’re in this time zone or this one, depending on who they are and where they are. There’s no way for the developer to code that into his app.
Historical developments need to be taken into account
A historian calls the developer and tells him that sometime back in the 18th century, we changed from the Julian calendar to the Gregorian calendar. It’s not that we lost about three weeks. It’s just that we skipped right from this date to this date, and missed the others. Can you code it so that it just kind of works that out for me?
This too can be coded into the app. But, there is no common order now. It’s a sort of a tangled mess that one has to deal with.
There are some additional provisions that a developer has to make as well. We can conclude that dealing with time zones for creating apps is complex work indeed.
