Thoughts on Daylight Saving Time and Its Effects on Business
What time is it? The answer isn’t always a simple one – particularly in states like Arizona and Hawaii that do not observe daylight saving time (DST). And this can be important for your business: nobody wants to reach out to a client at 8 am, only to find out it is 7 am their local time and they aren’t in yet.
Here in California, the topic of daylight saving time has been a point of contention recently. With the passage of Proposition 7 in November, our legislature now has the ability to either change the dates and times of DST, or even establish permanent year-round DST should the Federal government allow it in the future.
As a developer, this kicked off a series of questions about the history of DST, how changes to local observations of time would affect programmed systems, and the nightmare of non-unified time standards. I don’t work directly with highly time-critical applications such as Global Positioning Systems (GPS), network television, or transportation systems. However, time that matches country, state, and local rules and regulations is important to me. Many of the tools I use leverage location-based clocks: for instance, servers or databases often create timestamps based on the machine’s current time.
Imagine a simple scenario where you have a computer in California and one in New York. Their clocks will of course read differently, because New York is in a different time zone that is 3 hours ahead. Simple enough, but what would happen if DST were observed differently across different localities? Would that mean that, when DST is in effect, New York is only 2 hours ahead of California? What if different states chose different dates to start or end DST? What if they ignored it entirely? What about my poor servers in different states and the timestamps that they are generating? What does it mean for the parts of the United States that don’t currently observe DST?
You probably see where the questions are leading: how do we build tools on top of systems in different localities, and what if I want to build in timing related elements into my own software? Overcoming these challenges can be better addressed by first looking at a brief history of DST, and the regulations put in place to help solve this nonuniformity.
What is Daylight Saving Time? – a brief history
Daylight saving time has been observed in both the US and various European countries since the World War I. It was enacted to cut down on energy consumption. In 1918 the U.S. adopted this policy, but it only lasted through the end of the war. At the time the observation of DST was unpopular, likely due to earlier waking hours, and was repealed a year later.
DST was adopted again in the US during the second world war under the name of “War Time”. At the time there was no federal law dictating whether a state had to observe DST or not. This lack of regulation resulted in inconsistent observations of DST.
Finally, in 1966 Congress decided to try and fix the inconsistent observation issue by enacting the Uniform Time Act. It was not the be-all-end-all solution to the problem, but it was a step in the right direction to get most states to follow the same regulations.
How does Daylight Saving Time affect computers?
The modern approach to solving time-related issues is for computers to set their system time based on a well-established time server. This time server has the difficult task of maintaining the correct time by factoring in any regional differences in policies such as DST. Chances are your home computer came preconfigured to reach out to one of these time servers using the Network Time Protocol (NTP). This protocol helps to keep your machine’s time in sync.
The same protocol can be used on databases, web servers, or other systems to keep up to date. These servers remove the burden from the end user by automatically updating the time based on your regional time standards. This is why there is no more dialing the clock on your computer an hour forward on that Sunday in March.
This network of time servers is also the answer to my worry about maintaining the proper time despite the differences and changes in local time related policies. California can be free to vote on keeping or removing DST, and I can rest assured there are measures in place to properly handle the changes.
How knowledge of Daylight Saving Time helps businesses
Spurred on by the vote in California and the differing opinions on DST, I decided to take a deeper dive into how local regulations can affect my line of work. It became readily apparent that scheduling tasks would need to have knowledge of DST as well as time zones. With these two items in hand I could write a scheduling application to smartly notify the recipients of meeting requests based on their local time. They would get a meeting request based on their local time, instead of having to add or subtract hours based on the difference in their time zones.
To get started I would need to determine the offset from Greenwich Mean Time + 0 (GMT +0), now more commonly known as Universal Coordinated Time + 0 (UTC +0). The time zone offset of the recipient’s location in conjunction with a daylight savings indicator would allow my application to be built. Both a DST flag indicating if an address observes daylight savings time and a time zone digit are returned by several Service Objects services. DOTS Address Geocode – Canada, DOTS Address Geocode – US, and DOTS Address Insight could all be leveraged for their DST flag and time zone.
My application is just the tip of the iceberg. The DST flag in conjunction with time zone information can be leveraged to make better business decisions. These fields could be combined into applications that help facilitate smarter contact with your prospective clients. Knowing your client’s location allows you to determine an ideal time to reach out to them. In a similar vein, if you know your target’s ideal emailing hour, you can use their location to dictate when to send out your targeted marketing campaigns.
Sales calls, meeting coordination, and targeted email campaigns are just a few of the ways you can use the fields from Service Objects services to improve your business efficiency. Contact us to learn more ways you can leverage our services.