As a fellow engineer I feel a certain kinship with Dr. Drang, but his arguments in favor of Daylight Saving Time range from un-compelling to demonstrably untrue.
- For adults, a one-hour change should have little impact to sleep schedules: agreed
- DST cost studies are bullshit: probably; most cost studies are bullshit
- Children’s sleep patterns should adjust within two days: lucky you, my kids say otherwise
- Morning starts too early in Chicago: closed as “too localized”
- Scheduling issues are easily fixed with software: except that they’re not
Children
In my experience DST exacerbates the brutal summer sleep schedule of high latitudes in a way that has nothing to do with adjusting the clocks. In Seattle, the latest sunset of the year is at 9:17 PDT (9:52 in Spokane). Getting kids to go to bed is difficult; when twilight lasts until damn-near 10 pm it can be impossible. And this isn’t a two-day or even a two week adjustment: sunset in Seattle occurs after 7 pm PDT from spring forward through September 25th, 6 weeks longer than it would otherwise and in an abrupt rather than a gradual transition. But ultimately, long days aren’t a good argument for or against DST; at high latitudes winter days are really short and summer days are really long. That’s what you get when you live at high latitudes, and it lasts all summer.
Chicago and waiting in the cold
Civil twilight before 4 am is pretty early, and a decent argument for staying on Daylight rather than Standard time. That said, the desire to wake up late and take walks in the evening is a personal preference, not inherently superior to running before work and going to bed before Jeopardy. If you live in Chicago your summer days are almost 16 hours long. Use the time however you want; you’re not a prisoner, and you don’t need a clock’s permission (although it’d be nice to know it was set to the right time).
Asking the entire country to suddenly shift it’s day because you live at high latitude in the far eastern part of a time zone is pretty broad solution to a localized problem (even if you include New England). For example, the DST shift is less than the difference in sunrise and sunset times across US timezones, say Seattle to Las Vegas, Boise to Denver, Odessa to Chicago, or Louisville to Boston. We’re shifting time not creating it, so any inconvenience spared in Chicago1 has merely been foisted off on some other community to the East or West.
Fix it with software
This is the weakest defense of DST because even if software “should” be well-suited to solve DST scheduling problems experience shows it’s not. The DST rules change, and not all software can be updated. Fall back used to be before Halloween, now it’s after. Indiana used to allow counties to set their own DST rules, now the whole state goes together. Rules change, and billions of devices that keep time don’t run software—much less have a way for it to be updated in the wild. And even if they did, that software will need to be supported and there’d need to be a way to easily push it to all its users, a test that Microsoft Outlook failed several years ago and that Android probably fails today.
And even a software-defined clock that’s supported and can be easily updated needs to be correctly programmed, and programmers make mistakes. Poor implementation of DST is not just laziness, although that’s occasionally true and is another augment against why software can’t make the switch seamless. Even good programmers code bugs and the rules of time-keeping are just complicated and localized enough to cause mistakes.
And even if all of this goes perfectly, in order for a clock to correctly account for DST it has to know the date and where it’s located. This is easy for a modern smartphone or computer with GPS and a constant internet connection, but think of all the clocks for which it’s not true, all of which have to be manually changed twice a year:
- watches
- wall clocks (e.g. the clocks in schools, churches, and conference rooms high up on walls where people are prohibited by union rules, safety regulations, or common sense from climbing up to fix them in a timely fashion)
- microwaves, ovens, and toaster ovens
- clocks in cars
- etc.
So instead of putting forward a demonstrably false reason why DST should be made transparent through software, we have to acknowledge that the switch causes real problems that decades of experience have shown are not easily solved.
Weights and Measures
One of the clearly enumerated federal powers is the establishments of weights and measures, of which a calendar and timekeeping system are clearly a part, and the essence of any good measurement system is that it’s well-defined and consistent.2 DST fails this test by injecting chaos into an already pretty shaky system for date tracking.3 It has benefits, but also drawbacks, and it’s clear the cost-benefit analysis is non-obvious and that reasonable people can disagree. In this case the right answer is to pick one, Daylight or Standard, and stick with it.
-
As for kids at the bus, perhaps school starts too early in Chicago. My elementary school in Bellingham, WA (48°45′1″N) started at 9 am, in part I’m sure to mitigate the dark and cold of winter, and I see no reason Chicago can’t start school at a similarly reasonable hour, although I hear it’s bitter cold and miserable there in December regardless of time of day, so perhaps the problem is intractable. ↩
-
This is why English units are so terrible for engineering. Lbf and lbm alone should be enough to disqualify English units from serious use in engineering and science, and in fact in every modern country except America they have been. ↩
-
12 months varying in length between 28 and 31 days. Leap year rules that nest four conditionals deep. Leap seconds between GPS and UTC. About a dozen ways to write out dates. Some of this complexity is necessitated by orbital mechanics and some self-generated, but I see no reason to make thing even more complicated by adding DST. ↩