Who needs daylight savings time, anyway?

Let’s face it: daylight savings time is a pain in the butt. Not only do we feel a mini-jet-lag effect, feeling tired and hungry at odd times of day, for what, about a week or so, but then it also messes up our dashboards. Unless… you follow this dashboard best practice:

Express the nightly start time for your project in terms of the UTC time zone. Times expressed in UTC are constantly moving forward, monotonically increasing, paying no attention to the pesky local customs forced on us by the buffoons we elect to public office.

Here on the east coast of the USA, Clifton Park, NY, for example, we are…

…in the summer time:

• calling the local time zone “EDT”
• observing “daylight savings” time
• local time = UTC – 4 hours
• 01:00:00 UTC == 21:00:00 EDT

…and in winter:

• calling the local time zone “EST”
• observing “standard” time
• local time = UTC – 5 hours
• 01:00:00 UTC == 20:00:00 EST

Here’s how you can guarantee that you do not need to adjust anything on your CDash server, or in your CTestConfig.cmake file: choose the later of the two times in terms of the local time zone as your local job start time. For those of us in the northern hemisphere, that’s the summer time.

So in the example, we would start our dashboard runs on the submitting clients at or after 21:00 each night, in local time. 9:00 pm Eastern time (local) is certainly a reasonable time to start our dashboards, even if the nightly runs could have started at 8:00 pm during the winter. Setting it up once and then leaving it that way forever is certainly much easier than adjusting all your machines, your source code and your CDash server project settings every six months.

Here are the key points:

• Express the nightly start time in terms of UTC
• Start the client machines that submit in the local time zone at or after the later of the two equivalent local times

If you express your nightly start time in terms of UTC and then start your dashboards in a crontab entry or scheduled task scheduled in the local time zone *after* the later of the two times…… then everything will always run smoothly and you will *never* have to adjust your nightly start time or your dashboard settings or your client crontabs ever again.

We’ve done this in the CMake project since this commit last March:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bd50fad0d8f55b46d18b9b8051926ada5da0f55
Since that commit, and the corresponding change in the project’s CDash settings, we haven’t seen any weirdness when the time change comes… You can (and should!) do the same in your project — go for it!

Wow. Pretty cool.

(This blog post is valid until such time as Congress abolishes daylight savings time. Oh, wait, that’s right: this blog post is still valid even after that happens. But don’t hold your breath waiting.)