Computing Daylight Saving Time

Tomorrow is one of my favorite days of the year as we begin daylight saving time!

(Note of trivia: it's actually "saving" as in we're saving daylight, not "savings" like a savings account. I called into Rich Lederer on A Way with Words, about a decade ago, before Wikipedia was mainstream, to get clarification. Yet, even though I know this, it's still hard as hell to say "saving" instead of "savings.")

Tomorrow will only be 23 hours long as the ground beneath our feet literally changes time zones. Spring is just around the corner! Even in places like San Diego, where tomorrow will have two minutes and three seconds more daylight, it's still a time to celebrate as the days get "longer" even if it's just an illusion. Personally, nothing seems as gloomy as December's days when the sun sets before 5 p.m.

Tomorrow's task will be to set all of our clocks ahead an hour. Actually, most of us will adjust our manual clocks tonight, before going to sleep. However, for our smart clocks, like those in our computers and cell phones, it will happen automagically.

But, just how much magic does it take for computers to figure this out is more than meets the eye since daylight saving time is arbitrary. Even though my 2004 Honda Accord has the ability to set its clock via GPS, I'll still need to manually "spring ahead" because its software hasn't been updated since 2007, when the U.S. changed the beginning and ending dates for daylight saving time.

Over the past 15 years, I've done more than my fair share of coding to deal with date and time calculations. A common bug that I've discovered, on more than one occasion, is when programmers assume that there are 24 hours in a day. For example, to calculate when tomorrow is just add 24 hours to midnight, right? Obviously that's wrong. Add 24 hours to midnight when "falling back" and you'll still be on the same day.

Time is tricker than you'd think. While we all know the difference between noon and midnight, we have to stop and think about the difference between 12:00 a.m. and 12:00 p.m. A fool proof way to eliminate this mistake is to, instead, say 11:59 p.m. or 12:01 a.m.

Computers, on the other hand, don't have too much trouble keeping track of time. All it takes is a software update to handle changes to when daylight saving time is observed. Internally, computers simply keep track of Greenwich Mean Time and then just apply an offset, plus or minus hours and minutes, to figure out local time. Actually, the time offset is usually measured in seconds, but that's probably overkill. Most timezones in the world are at the top of the hour when GMT is at the top of the hour. But, there are a some outliers where it's the bottom of the hour or the quarter of the hour when GMT is at the top of the hour. I'm not aware of any funkier timezones other than a quarter of the hour difference.

A gotcha that I learned, probably since I've never observed daylight saving time in London, is that the local time in London doesn't always correspond to GMT since London also observes daylight saving time better known as British Summer Time.

One question that popped in my mind, today, was, why don't we invoke daylight saving time on Saturday mornings instead of Sunday? It seems that we can pick and choose when we want to observe it.

When I was in the Marines, embarked aboard ship and sailing due east or west for days or weeks at a time, we observed timezone changes every other day. In all my experiences while sailing the seven seas we always sprang ahead or fell back at 7 p.m. ship's time. So, when we were traveling to the west, we'd have two 7 p.m.'s (AKA 19:00 military time) which was always a treat as long as you weren't on duty or standing watch during the evening.