2 min read

The 25 hour day

A few months ago, a blog post made the rounds on Falsehoods Programmers Believe About Time. Here are two assumptions that could have gotten you into trouble this week:

  • There are 24 hours in every day.
  • Time always moves forward.

On Sunday at 2am, we rolled our clocks back an hour. One minute it was 1:59 a.m., and the next, it was 1:00 a.m..

It’s common in web development to run maintenance tasks in the early morning, when server traffic is at a minimum. If you have a task that runs every day at 1:15 a.m., on Sunday it ran twice. If you have a task that runs once an hour, on Sunday it ran twenty-five times.

Maybe that’s better than what happens to a task set for 2:15 a.m. on Sunday, March 11th, which is to say, nothing. There is no 2:15 a.m. on March 11th. The day that marks the start of daylight saving time (not daylight savings time) has only twenty-three hours.

Of course, this assumes your clock is set to a timezone that participates in daylight saving time. You could have two servers operating ten miles apart: one in Indiana, one in Illinois, and if both were set to local time on Sunday, one had a twenty-five hour day, the other twenty-four. One minute their clocks were in sync, the next they were an hour apart.

This is one reason why building software often takes longer and costs more than expected. Not specifically because of timezones: DST issues are predictable, and there are a number of best practices to avoid them.

It’s because there are always gotchas. If there are exceptions to “facts” like “There are 24 hours in a day,” imagine how many exceptions there are to the rules that govern the web application you dreamt up three months ago. Assumptions like:

  • A user will never need to change their email address.
  • A product will never be assigned to more than one category.
  • Everyone will have a unique social security number. (One of my favorite gotchas comes from the California Department of Education, where they have over two hundred kids without an SSN named “Juan Garcia.”)

There are exceptions to almost every assumption, and they often aren’t apparent until you start writing code, or until you put the product in front of the customer. Seemingly simple problems tend to become more complex the longer we look at them.

This is why we don’t sign fixed bid contracts, and why we don’t reply to RFPs. It’s why we start our projects with a thorough inception process where we ask “Why?” more in two days than your annoying four-year-old kid, and why we use Agile development to stay light on our feet so that we can juke-and-jive as requirements change.

And it’s why we’re skeptical whenever someone comes to us and says, “I already have the wireframes, I just need you to code it,” because if we asked that same person how many hours are in a day, they’d swear the answer is twenty-four.