Most people across the U.S. lost an hour of sleep last weekend. While the reason is the simple “spring forward” to Daylight Saving Time (DST), there are also significant hidden costs to time changes which should make us all lose more sleep.
DST is like a bad Product Manager
In 1784, Benjamin Franklin suggested that Parisians change their sleep schedules to save candles and lamp oil. However, Daylight Saving Time is a relatively new invention. The Germans originally devised Daylight Saving Time (DST) in 1916 in an effort to conserve energy during World War I. The U.S. formally adopted the Uniform Time Act in 1966, though States retain the ability to opt-out (e.g. Arizona and Hawaii).
Even more confusing is that DST, like Timezones, varies across the world by country and administrations. There are currently 13 different daylight saving time definitions, including Lord Howe Island, Australia that varies by just 30 minutes!
In 2005, Congress extended DST by 4-weeks. Ostensibly to conserve energy. But since the shift was from the last Sunday in October to the first Sunday in November, it is widely assumed that “Big Candy” lobbied for more Halloween “trick-or-treat” time and therefore more candy sales.
The U.S. Department of Energy reported in 2008 that the additional weeks of DST saved 1.3 Tera Watt-hours of electricity, approximately 0.03% of the national electricity usage in an entire year. The total cost saved was estimated at $84 million..
These efforts are for the stated goal of reducing costs and increasing happiness. But what if DST is doing the opposite – costing more money and making people miserable. In 2016, research reports estimated that Daylight Saving Time could cost the U.S. between $430 million to $1.7 billion per year due to lost productivity, physical injury, and other livelihood or productivity setbacks.
Hidden from view are the bugs in software that increasingly are powering, and bringing down, power grids, transportation systems, banks, and governments. However, there are many signals that there is an even higher significant economic and health cost to DST and related time changes.
We likely all know about Y2K which did not cause major issues thanks to planning and updates ahead of this singular event. Now consider that same scenario repeated every few years and across governments. Since 2015, at least 45 U.S. States are considering changing their use of DST – a pending wave of ad-hoc changes that could have significant impact on software reliability.
Unstable Code in an Unstable Time
Engineering aims to build & maintain stable solutions that people can rely upon. Software in particular operates in a various environments that do not always fit a simple model. While this is just part of the responsibility for engineering, when the requirements are constantly changing it can be difficult, and expensive, to ensure things work as expected.
Time is already a complicated domain to develop correct, maintainable software. I once heard about a software engineering interview question that asked developer candidates how they would design and implement an algorithm for a recurring calendar event based on Boston parking signs.
Now consider when the rules of time vary by geographic location, day of the year, and changing policies. This is a ripe condition for both bugs as well as confusing user experiences.
This is compounded because Software doesn’t have physical restrictions. Code needs to work consistently based on static, dynamic, and semantic conditions.
- when & where the user is located
- when & where they’re interacting with
- the policies at that future or past location + time
- continue to work as the user moves through time + space!
There are emerging, publicly available examples where DST and time changes are causing significant issues. I’ve found a few worth highlighting…
- Microsoft warns national governments about bugs due to DST changes. Microsoft now has a “DST Blog” and help docs.
- Apple iOS users across Canada had clocks off by an hour – which coincided with European, but not Canadian, DST change. There have been similar Apple Watch issues.
- Schneider Electric, a $34-billion annual revenue power company, discovered a bug in their power meters that requires a patch update.
- MySQL, one of the most popular databases across the world used in commercial and consumer software systems, has erratic DST behavior
There are likely many more publicly available, and internally confidential, time-related bugs that are not readily disclosed. However, there is continuing evidence where workers, even in life-threatening scenarios, are required to work around bugs with DST.
Were you alive between 1-2am last night?
During Daylight Saving time changes, some medical staff opt for paper records because Healthcare systems can result in deleted records.
Hospital staff have learned to deal with it by taking extra chart notes by hand. ICU Nurses “come to expect that the vitals she enters into the system from 1 a.m. to 2 a.m. will be deleted when the clock falls back to 1 a.m. One hour’s worth of electronic record keeping “is gone,” she said.”
Sometimes, people just work around the software bugs. John’s Hopkins Hospital and Cleveland Clinic “enter vitals at 1 a.m. and then when the clock falls back an hour later and they have to enter new vitals, they list them at 1:01 a.m. They leave a note that it’s an hour later, not a minute later.“
Calculating the cost
To the original point – what is the total cost of Daylight Saving Time changes?
I couldn’t find a summary analysis of the cost due to bugs caused by DST, there are some parallels. Software bugs caused by Y2K was estimated to cost $21 billion in 2002 and the 2005 DST change cost $350 million. Overall, some estimates of overall software bugs exceeds $2 trillion per year.
While not all bugs are caused by DST and time-related issues, as software increasingly powers all of our systems the costs, and related impacts, will continue to grow.
If you want to learn more details about the history and policy implications of Daylight Saving Time then I recommend reading the 2020 Congressional Research Report. Disclaimer: one of the authors is my spouse, so you can imagine the geekiness of our family conversations.