QSO Log & ADIF Export
Logs are kept in UTC — which puts most of an American evening on tomorrow date. Logs contacts, exports ADIF, stays in your browser.
Your log
Stored in this browser only. Nothing is uploaded.
How much of your operating lands on a different UTC date
Duplicates you should expect by chance
Why your Saturday evening is logged on Sunday
Amateur logs are kept in UTC, and the flat arithmetic of that is easy: the share of the day where the UTC date differs from your local one is exactly your offset divided by twenty-four. On the US Pacific coast that is 33 per cent, in Hawaii 42, in Japan 37.5. The part that is not easy is which hours those are. West of UTC the shifted window is the evening — from 16:00 local in California, from 19:00 on the east coast — which is exactly when people operate. East of UTC it is the early morning, when almost nobody does.
So the same rule bites very unevenly, and the ordering inverts. Weighted by when people actually get on the air, a US Pacific operator has roughly 59 per cent of contacts on a shifted date against a flat 33. Japan has the larger flat offset — 37.5 against 33.3 — and a much smaller real impact, about 19 per cent, because its shifted hours are dead. Rank the world by offset and you get one answer; rank it by contacts actually affected and California and Japan swap places. Those weighted figures rest on an assumed profile of when people operate, so treat the exact percentages as illustrative — but the inversion holds under any profile that peaks in the evening.
Duplicates work the same way — a structural effect people mistake for carelessness. With P active stations and N contacts, the expected number of repeated pairs is about N(N−1) over 2P, so 200 contacts against 500 active stations produces around 40 repeats purely by chance. Because it grows with the square of contacts, it goes from negligible to unavoidable quickly, which is why every contest log checks duplicates automatically rather than trusting anyone's memory.
How to use
- Enter a callsign and press the log button — the UTC time is taken automatically.
- Watch the date warning in the evening; the UTC date rolls over before yours does.
- Export ADIF regularly, because the log lives in this browser only.
- Check the duplicate flag before submitting a contest log.
Frequently asked questions
Why do ham radio logs use UTC?
So that two stations on opposite sides of the world write down the same moment. If each logged local time, confirming a contact would need both operators to agree on two time zones and any daylight saving between them, and awards spanning the globe would be unworkable. One clock for everybody removes the ambiguity entirely, at the cost of it not matching the clock on your wall.
How much of my operating falls on a different UTC date?
Exactly your offset divided by twenty-four, as a share of the day — 33 per cent on the US Pacific coast, 42 in Hawaii, 21 on the US east coast. But that flat figure understates it badly for anyone west of UTC, because the shifted hours are the evening, which is when people actually operate. Weighted for that, a Pacific operator is nearer 59 per cent.
Does the UTC date problem affect everyone equally?
No, and the ordering inverts, which is the surprising part. Japan has a larger offset than the US Pacific coast — 37.5 per cent of the day against 33.3 — but a much smaller share of contacts affected, roughly 19 per cent against 59, because its shifted hours are the dead early morning while California ones are prime time. Rank by offset and by contacts affected and the two swap places.
Why is my Saturday evening contact logged on Sunday?
Because from 16:00 local on the US Pacific coast, or 19:00 on the east coast, the UTC date has already rolled over. That is correct rather than a mistake, and it is the date awards, contests and confirmations use. It is also why a contest defined as running on a particular UTC day either starts while you are at work or ends before your evening does.
What is ADIF?
The interchange format that essentially every logging program reads and writes. It is deliberately plain text: each field is written as its name, its length in characters and its value, with each record ending in an EOR marker. That length prefix is why a hand-edited ADIF file fails loudly rather than silently — a mismatched count is detectable, where a comma-separated file just shifts columns.
How many duplicate contacts should I expect?
More than intuition suggests, because it is the birthday problem. With P active stations and N contacts the expected number of repeated pairs is about N times N minus one, over 2P — so 200 contacts against 500 active stations gives around 40 repeats purely by chance. It grows with the square of contacts, which is why it goes from negligible to unavoidable so quickly.
Are duplicate contacts a sign of careless operating?
Usually not. They are a structural consequence of making many contacts from a finite pool of active stations, and the arithmetic says they are unavoidable at any real contest volume. This is exactly why every serious contest logger checks duplicates automatically and why trying to hold the list in your head stops working after the first hour.
Where is my log stored?
In this browser, using local storage, and nowhere else. Nothing is uploaded, there is no account and no server holds a copy — which also means it works with no connection once the page has loaded. The flip side is that clearing your site data deletes it, and it does not follow you to another device, so export the ADIF for anything you would mind losing.
Can I import an existing log?
Not into this page. It writes ADIF but does not read it, because parsing the format properly means handling a great many optional fields and vendor extensions that a simple logger has no use for. If you already have a log in another program, keep it there — this is for casual operating and for getting contacts out in a format that program can read.
Is this suitable for contest logging?
For a casual entry, yes; for a serious one, no. There is no radio control, no serial number sequencing, no cluster integration, no real-time duplicate warning as you type and no support for the exchange formats individual contests require. A dedicated contest logger does all of that, and the difference matters once the rate goes above a contact a minute.
What should I record for each contact?
Callsign, UTC date and time, band and mode are the minimum that makes a contact confirmable, and everything else is optional. Signal reports are conventional and rarely disputed; grid square is worth having for VHF and for distance-based awards; a comment is worth more than people expect when you come back to a log years later and want to remember the conversation.
Does daylight saving affect UTC logging?
Not the UTC time itself, which is why it is used — UTC has no daylight saving anywhere and never shifts. What changes is your offset from it, so the local hours that fall on a different UTC date move by an hour twice a year. An operator who has learnt that the date rolls at 16:00 has to relearn 17:00, which is a small but real source of logging errors each spring and autumn.
🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.