It's about time

A few weekends ago the ARRL CW Sweepstakes contest was held. It was also the weekend where, in the United States, the time "changes" from Daylight Savings Time to Standard Time. I won't go into the history of DST, or Summer Time, since the web is full of resources that discuss that ad nauseum. I'm also going to show some restraint and not launch into a full tirade (just a little grumbling) about how pointless it is and how especially stupid it is that the goverment of the United States decided to change the start and stop times last year, costing many millions of dollars to have all kinds of software and other equipment changed, while actually increasing energy use. (A recent article about that is here, one from spring 2007 is here.) No, I'm not going to talk about that.

What I am going to talk about is the surprising level of misunderstanding that some hams seem to have about telling time.

Why is time important for hams? There are lots of reasons but I want to address two in particular. The first one is that when a ham makes a contact on the radio and wants to exchange QSO (contact) information, in the form of a QSL card or electronically, we need to agree on a standard time reference to use. In case the reason for this isn't obvious, because contacts are often made across time zones, if I log the contact time in my local time, it's not the same time (and in some cases, even the same date) at the other end. It can be confusing to try to validate a contact where the time (and date) don't match what you expect. For example, I'm typing this at 6:44PM local time on Sunday, November 9. If I were to make a contact with my friend Bruce, XW1B in Laos, if he were to log that contact in local time, his log would say 6:44AM on Monday, November 10. Instead, we both just log that the contact was made at 23:45 (the same as 11:45PM) UTC or Zulu (which is essentially the same as GMT), on Sunday, November 9, and all's well. (As an interesting aside, there actually is a difference between GMT and UTC, the Wikipedia article is pretty interesting if you're interested in that kind of thing.)

One thing that has happened to me a number of times is when a fellow ham gets the UTC time correct, but gets the date wrong. I've gotten cards that had the correct time (in UTC) but the date was wrong. This typically happens when the UTC time has gone to the next day (such as in my example above). I suspect that some of those are honest mistakes, but I do recall an email exchange with a ham a few years back where he insisted that since the day hadn't changed at his location, the day remained the same. I think that I finally managed to convince him otherwise.

The other reason that I wanted to mention is that for certain special events, and in particular, for contests, hams need to know when the contest starts and when it ends. Unlike the discussion above where it's only a single point in time, a contest involves a period of time. Clearly you should neither operate prior to the start of the contest nor after it ends. Since most contests involve participants, the start and end times are usually specified in UTC. Very simple, right?

Well, I thought so, but apparently not everyone does. A few weeks ago, just before the ARRL CW Sweepstakes contest that I mentioned earlier, someone posted to one of the mailing lists that I receive asking if there would be more hours to operate since the clocks would go back one hour in the middle of the contest. He then went on to ask how to deal with the "fact" that since the time between 1AM and 2AM occurs twice when "falling back" his log entries wouldn't be correct. (In the US, when changing between DST and Standard time, the change is made at 2AM local time. When going to DST, the local clocks jump from 2AM to 3AM. When going the other way, the hour between 1AM and 2AM occurs twice. Remember that this is only the local time.)

My response to him was that since the contest start and stop times are specified in UTC, and UTC, by definition doesn't adjust for DST, that there were still the same number of hours between 2100 UTC on the 1st of November and 0300 UTC on the 3rd of November this year as there are, and have been, every other year. Further, since logs have to be submitted in UTC anyway, why not just log in UTC and not worry about any kind of conversion? Although I did respond directly (not on the mailing list) to the person who asked the question, I never received a response.

Personally, I always log in UTC, even on those rare occasions (like when I was operating from the boat as K2NUD/MM) when I use paper. It's not hard to figure out the local time difference, and once you start, there's nothing to it. My computer logging programs automatically log in UTC, I keep the clock on the display on my Icom 756 Pro II set to UTC, and I have this nifty program called Qlock that allows me to display local times all over the world (that's how I knew what time it was for XW1B but also shows UTC. It's easy. If you don't use a computer for logging or don't have a program like Qlock, you can use a website like timeanddate.com to find out the current time in GMT. If you don't have a computer (hey ... how are you reading this?) you can always tune to WWV on 2.5, 5, 10, 15, or 20Mhz which transmits the time in Coordinated Universal Time (aka UTC). Remember that UTC is the same no matter where you are in the world!