fix(dxcc): a retired prefix is not a wrong one

Reported from a real import: every ZK2 contact came back New Zealand and
Niue vanished from a DXCC that had it confirmed. cty.dat is not wrong,
it is CURRENT — Niue moved to E6, so ZK2 reverted to New Zealand there.
ZK1 loses the Cook Islands the same way, and the reporter was right to
suspect more.

ClubLog's prefix table is date-ranged and still knows both, which is the
whole reason for enabling its country file. We consulted it only for
callsigns that already HAD a per-callsign exception — so a ZK2 with no
exception never reached it. It is now asked whenever no exception covers
the QSO's date.

Two limits keep the blast radius honest. It never overrules an exact
'=CALLSIGN' entry in cty.dat — that is somebody having looked at this
very callsign, and a prefix rule does not overrule it, which is why
Match now says how it matched. And where ClubLog has no answer (E6, TO5A
and their like are absent from its prefix table) cty.dat still decides,
because silence is not an answer. Measured before changing: on a sample
of thirty calls the two files agreed on twenty-eight, and both
disagreements were this bug. Opens 0.27.11.
This commit is contained in:
2026-09-03 22:11:55 +02:00
parent 4dbc773343
commit b00552f617
4 changed files with 103 additions and 9 deletions
+20 -8
View File
@@ -10249,14 +10249,26 @@ func (a *App) applyClublogException(q *qso.QSO, force bool) bool {
}
e, ok := a.clublog.Resolve(q.Callsign, date)
if !ok {
// No exception COVERS this QSO's date. If the call nonetheless HAS a
// date-ranged exception (e.g. G1T = Scotland only from 2024-02-21), then
// cty.dat's date-blind "=G1T → Scotland" override is WRONG for an older
// QSO — resolve it by ClubLog's date-aware PREFIX table instead (G1 →
// England for a 2012 contact). Ordinary calls (no exception) are left to
// cty.dat.
if a.clublog.HasException(q.Callsign) {
if pe, pok := a.clublog.ResolvePrefix(q.Callsign, date); pok {
// No exception covers this QSO's date, so the question becomes which
// country file knows the PREFIX better.
//
// ClubLog's prefix table is date-ranged and cty.dat's is not, and that
// is not a detail: cty.dat describes the world as it is TODAY. Niue
// moved to E6, so ZK2 went back to New Zealand there — and every ZK2
// contact ever made was silently relabelled New Zealand, taking a
// confirmed entity out of an operator's DXCC with it. ZK1 loses the
// Cook Islands the same way. ClubLog still knows both.
//
// It only speaks when it HAS an answer (E6, TO5A and their like are not
// in its prefix table at all), and never over an exact "=CALLSIGN" entry
// in cty.dat: that is somebody having looked at this very callsign, and
// a prefix rule does not overrule it.
if pe, pok := a.clublog.ResolvePrefix(q.Callsign, date); pok {
ctyExact := false
if m, mok := a.dxcc.Lookup(q.Callsign); mok {
ctyExact = m.Exact
}
if !ctyExact {
e, ok = pe, true
}
}