Making up for lost time (UTC vs. DST)


Did you oversleep this morning? If you live in the United States of America, Monday morning seems to have arrived just a bit earlier, accompanied by a bit more "dark" than usual.

That's because as good time-fearing citizens, we have all set our clocks ahead by one hour so as to conserve more daylight for the end of the day. It means that on Saturday night/Sunday morning, we give up an hour of sleep.

We also lose additional time as we wander around our houses and set our many dozens of clocks ahead by 60 minutes. Several years ago, in an effort to save my clock-setting labor, I purchased one of those "never-have-to-set-it-again" alarm clocks. It featured an internal battery (to guard against power outages) and sophisticated circuitry that already knew about Daylight Savings Time. With this new clock, I would never have to worry about waking up too late (or too early) on the two designated Sunday mornings each year.

But guess what? Shortly after I bought the clock, Congress changed the Laws of Time and effectively extended DST by about a month. My "smart" clock was now remarkably stupid. Not only did it fail to automatically adjust the time when it was supposed to, but it actually continued to adjust the time according to the old schedule, thus interfering with my sleep patterns on two errant weekends per year while offering no help on the "official" time-change dates. John D. Cook says that "DST is a huge mess", and for a while in my household, it was extra messy.

Now I try to make sure that every new clock that I buy can connect to the Internet. Why? Because Internet-connected devices track time in UTC, and not in local time. For display purposes, our devices provide the arithmetic service of calculating the UTC value into "local" time. And although that formula might change a couple of times per year (UTC-5 instead of UTC-6), the devices take care of all of that for me.

UTC is used for most computer-related activity that features time stamps, thus providing an objective measure of time without local bias. But sometimes we encounter data that doesn't use UTC and we must adjust our analysis accordingly. That's why it's important to know how to calculate the UTC offset within your SAS programs. And you can also use SAS to plan ahead, and note exactly which future Sundays will be affected by DST. That is, until the DST debate results in more changes.


About Author

Chris Hemedinger

Senior Manager, SAS Online Communities

+Chris Hemedinger is the manager of SAS Online Communities. Since 1993, Chris has worked for SAS as an author, a software developer, an R&D manager and a consultant. Inexplicably, Chris is still coasting on the limited fame he earned as an author of SAS For Dummies.  He also hosts the SAS Tech Talk webcasts each year from SAS Global Forum, connecting viewers with smart people from SAS R&D and the impressive work that they do.


  1. The only time is the number of seconds since the beginning of the UNIX Epoch (1970). The rest is an arbitrary mathematical conversion. ;)

    Also, are you ready for the other leap this year?

    • (also, you should be running an NTP server on any devices capable of it. It keeps the time on your system by synchronizing against servers you specify (e.g. [0-3] ) and also corrects for your local clock's drift.)

  2. Andrew Howell on

    Similar story down under. After World War I, Melbourne built a "Shrine of Rememberence" - a lovely war memorial that included a light aperture that causes the sun to shine on the tomb of the unknown soldier at exactly 11am on 11th of November (when WW1 ended.) It was built to be accurate for over 1000 years.

    Then a few years later the government introduced daylight savings..

    So now they use a mirror to "fudge" the effect at the official time of 11:00am (Daylight Savings Time), and an hour later - when the official ceremony is over and the dignatories have left - the public can enter and see the effect for real at midday (11:00 am Standard Time).

    Go figure..

Leave A Reply

Back to Top