Whether you live in Traverse City Michigan, Houston Texas, London England, Perth Australia, or anywhere in the world for that matter, time zones impact your lives on a daily basis. The sun rises and sets across the globe, yet we’ve come to adopt a system that seemingly puts those living in countries such as Australia several hours ahead compared to those living on the other half of the globe in the United States or other countries hours away. When those of us in the Eastern Standard Time Zone are rising and shining to our morning coffee and toast, those in Madrid Spain are taking mid-afternoon siestas per their geographic location as part of the Central European Time Zone. Figure 1 provides an example of the various local times across the globe at any given time. This begs the question; how do we keep tabs on dates and times, in order to make sure everyone’s in sync?
Figure 1: A visual representation of the variance local time across the globe. 8am in New York would equate to 1pm in London.
Source: Sapling Syncronized Clock Systems
I came across in interesting article written by Mike E. Yeager titled Does Anybody Really Know What Time It Is: Dates and Times across Time Zones (found here) published in the latest edition of Code Magazine which explores managing dates and times across time zones from a software engineer’s perspective, and the caveats surrounding this topic. Mr. Yeager focuses in on how Microsoft’s .NET framework handles dates and times including a brief history of such, along with his dream solution to solve the world’s struggle of storing dates and times, and keeping them all synchronized within a software solution. Sparing the majority of the technical details, the article breaks down a couple .NET function calls, discusses SQL data types, and describes best practices.
In being an aspiring software developer, this article was an intriguing look into how complicated a seemingly easy problem can become, and how implementations of the date and time system change over the years, and sometimes not for the better. Prior to reading through this article, I’ve had professional experience in dealing with date and time across multiple time zones. By testing scheduling software for a number of years, there’s always a certain country who decides to begin observing DST rules, while others decide against it for various reasons. A common use case for international scheduling software would be an instance in which coworkers across various time zone decide to plan a meeting that occurs at an appropriate time for all involved parties. In other words, a meeting starting at 5pm EST isn’t very convenient for those living in the UK, where local time would equate to 10pm GMT, and conversely a 9am GMT meeting would cause issues for those living in EST by needing to wake up bright and early at 4am.
Having the ability to adapt to the rapid change put forth by world nations will give your product the competitive advantage not only in the scheduling software industry, but in any other business sector. I don’t think it’s any secret when I say that companies with the capability to offer robust simple solutions to common problems will succeed in business. Dates and times are only one of the many factors for consideration when designing an enterprise software product. There’s no time to waste, the clock is ticking. Tick. Tock.
Resources:
Yeager, M. (2017). Does Anybody Really Know What Time It Is: Dates and Times across Time Zones. Code Magazine, Nov/Dec 2017 Issue. Retrieved from http://www.codemag.com/article/1711111
Round Analog Time Zone Clock |Online Image|. (2017) Retrieved November 6, 2017, from
