UTC for Amateur Radio: Why Hams Log in UTC

Why ham radio runs on UTC

A station in Tokyo logs a rare DX contact in São Paulo. Tokyo is on Japan Standard Time, UTC+9. São Paulo is on Brasília Time, UTC-3. If both operators log in their own local time, the timestamps differ by twelve hours. The QSO record becomes useless for awards or confirmation.

UTC fixes that. When both stations log in Coordinated Universal Time, the timestamp is identical. UTC never observes daylight saving time: its offset stays UTC+0. That stability is why the International Amateur Radio Union and most national societies recommend UTC for all on-air activities.

Logging contacts: always in UTC

Every serious logbook records the date and time in UTC. Paper, spreadsheet, logging software like N1MM, DXLab, or Logger32: all default to UTC. The standard format is YYYY-MM-DD HH:MM.

Why does this matter for award chasing? The DX Century Club and Worked All Zones programs require UTC timestamps. If you log a contact in local time and later try to confirm it via the Logbook of the World system, the mismatch will reject the QSO. Log in UTC from the start, and you never have to convert backwards.

DXpeditions and contests

DXpeditions publish their operating schedules in UTC. A rare-island activation might say "active 06:00-12:00 UTC daily." If you live in Los Angeles, 06:00 UTC is 10:00 PM PST the night before in January, not the same calendar day.

Contests run entirely on UTC. The CQ World Wide DX Contest starts at 00:00 UTC on the last full weekend of October. Arrive at 00:00 local time and you have missed hours of the contest. Logging software converts UTC to your local clock for operating, but the log file stores everything in UTC.

Converting UTC to your local time for nets

Many nets announce their meeting time in UTC. A net that meets "every Wednesday at 20:00 UTC" requires you to convert. Here is a reference for 15 January 2026 and 15 July 2026:

If a net is at 20:00 UTC in January, that is 3:00 PM in New York. In July, the same net is 4:00 PM in New York because New York shifts to Eastern Daylight Time. London moves the opposite way: 20:00 UTC is 8:00 PM GMT in winter, but 9:00 PM BST in summer.

UTC and propagation

Propagation predictions use UTC. The grey line, the terminator between day and night, moves across the globe in a predictable cycle. Operators working the grey line calculate local sunrise and sunset times in UTC, then convert to their local clock.

Solar data from space weather agencies is timestamped in UTC. Solar flux, K-index, and A-index readings are all UTC-based. When you check propagation conditions, the data is current as of the latest UTC hour. Compare it to your local time without converting, and you are looking at conditions from a different hour.

Common UTC mistakes new hams make

Mistake one: logging the local date. If you work a station at 01:00 UTC on January 15, the local date in New York is still January 14. Log the UTC date, not your wall calendar date.

Mistake two: forgetting DST shifts. Your logging software may handle this, but if you manually convert, remember that London is not always UTC+0. In July, London is UTC+1. The same applies to New York and Los Angeles.

Mistake three: using AM/PM. UTC uses the 24-hour clock. 14:00 UTC is 2:00 PM, not 2:00 AM. Mixing AM/PM in a contest log is an instant disqualification.

Mistake four: assuming all zones change DST on the same day. Europe and North America do not shift on the same dates. For two weeks in March, the offset difference between New York and London is not the usual 5 or 4 hours. It narrows to 4 hours during the overlap.

Next step: Set your logging software to display UTC on the main screen. When you check a DXpedition schedule, convert the UTC times to your local clock once and write them down. That habit saves you from missed contacts and rejected QSLs.