| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |
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.
| This post was kindly contributed by The SAS Dummy - go there to comment and to read the full post. |