fix(adif): read 4-digit HHMM QSO times as HH:MM:00 on import

[patrickrb]

Problem

ADIF's Time type is HHMMSS or HHMM (seconds omitted). When a logger emits a 4-digit TIME_ON/TIME_OFF, Nextlog imported it at the wrong time of day.

adifDateTimeToUtc left-padded the time to six digits:

const timeStr = adifTime.padStart(6, '0'); // "2359" -> "002359"

So 2359 (23:59) was parsed as 00:23:59, 1230 (12:30) as 00:12:30, and so on. Every QSO imported from a logger that omits seconds landed at the wrong time — and a late-evening contact near midnight could even shift onto the wrong calendar day.

4-digit times are valid ADIF (and appear in this repo's own parser fixtures, e.g. <time_on:4>2359), so this silently corrupted real imports. WSJT-X-style HHMMSS logs were unaffected, which is likely why it went unnoticed.

Solution

Pad on the right (append "00" seconds) instead of the left, and clip over-long values to six digits:

const timeStr = adifTime.length >= 6 ? adifTime.slice(0, 6) : adifTime.padEnd(6, '0');

adifDateTimeToUtc is now exported (it was module-private) so it can be unit-tested as a pure function, and carries a doc comment explaining the HHMM/HHMMSS rule.

The QRZ ADIF path (src/lib/qrz.ts) already parses HHMM correctly (it slices left-to-right with seconds defaulting to 0), so no change was needed there.

Testing

• New tests/adif-datetime.spec.ts: covers HHMMSS, HHMM at noon/midnight/23:59, and an unparseable date returning null. Confirmed the two HHMM cases failed before the fix and pass after.
• npx playwright test adif-datetime adif-parse adif-generate — 28 passing.
• npm run typecheck, npm run lint, npm run build — all clean.

Future follow-up

None required. The fix is isolated to the one conversion helper.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nodelog	Ready	Preview, Comment	Jul 24, 2026 1:16am