by Nick Toscano
The first leap year was introduced with the Julian calendar over 2000 years ago. It wasn’t until 1582, when the Gregorian calendar was adopted, that special rules were applied to omit three leap years every 400 years to account for a small, yet significant time difference between the solar year and the annual calendar.
February 29th presents a perfect trial for developers. It enforces the idea that programmers must take into account rare yet inevitable events in their application testing.
Time has often tested programmers, and rightfully so. There are 40 different global time zones that are often unrelated to a country’s physical location. There are also many unique ways of implementing daylight savings time that further complicate the situation. So when dealing with time, your best bet is to stick with native classes and proven methods for dealing with the irregularities of the clock.
Creating custom solutions can have disastrous results if not tested properly. On December 31, 2008, thousands of Zunes (Microsoft’s failed response to the iPod) bricked almost simultaneously all due to a small, overlooked flaw in logic that trapped each device in an endless loop. In 2012, Microsoft’s integrated cloud platform, Azure, was down for 12 hours due to a leap year bug.
How is it that this one extra day can cause so much trouble? Well, it’s quite simple actually. Most systems account for a 365 day year. If anything is set on up on an annual basis, it counts down from 365 and then repeats itself. But there are 366 days in a leap year. If this isn’t taken into account, events might occur too early on the backend of an application – or not at all. On the front-end, users might be served inaccurate data or become locked out of a system. This is certainly not the experience any developer wants to be responsible for.
A lesser known, yet harder to manage “leap” event is the leap second. The leap second rectifies the differences between atomic time and solar time caused by irregularities in the Earth’s rotation. Unlike the leap year, the leap second does not occur at regular intervals. This poses a serious challenge to developers as leap seconds are only announced six months prior to their occurrence.
The most famous method of dealing with the leap second is Google’s Smear Technique: they distort time on their servers to account for one extra second by adding milliseconds to each second in a 24 hour time period. This ensures that everything remains relative, and they don’t need to have a record that exists at an irregular 61 second mark.
The trials and tribulations of dealing with time are very real, so be cautious. Anomalies in time will break your code, so sticking with open source packages and the best practices that have been proven to work will save you time – and quite a few headaches.
[Image Source: Shutterstock.com]
