Bug: arinc_702_helper.processDateCode computes a swapped DDMMYY→MMDDYY date and then never uses it (likely missing NaN fallback)

[kevinelliott]

Summary

processDateCode in lib/utils/arinc_702_helper.ts builds a locally-swapped date string and then drops it on the floor — the value computed into date is never read. The code reads as if it were copy-pasted from the sibling Arinc702Helper.processTimeStamp in the same file, which performs the same swap but uses it as a NaN fallback. The fallback got lost in processDateCode, so dates that the first convertDateTimeToEpoch call cannot parse silently become NaN in decodeResult.raw.message_timestamp instead of being retried with the swapped MMDDYY form.

Affected code

lib/utils/arinc_702_helper.ts:522-535

function processDateCode(decodeResult: DecodeResult, data: string[]) {
  if (data.length === 1) {
    // noop?
  } else if (data.length === 2) {
    // convert DDMMYY to MMDDYY - TODO figure out a better way to determine
    const date =
      data[0].substring(2, 4) +
      data[0].substring(0, 2) +
      data[0].substring(4, 6);     // <-- computed but never used
    const time = DateTimeUtils.convertDateTimeToEpoch(data[1], data[0]); // HHMMSS
                                                          // ^^^^^^^ uses unsorted data[0], not `date`
    decodeResult.raw.message_timestamp = time;
  }
}

Compare to the working processTimeStamp (same file, ~lines 222-242):

let time = DateTimeUtils.convertDateTimeToEpoch(
  data[0],
  data[1].substring(0, 6),
);

if (Number.isNaN(time)) {
  // convert DDMMYY to MMDDYY - TODO figure out a better way to determine
  const date =
    data[1].substring(2, 4) +
    data[1].substring(0, 2) +
    data[1].substring(4, 6);
  time = DateTimeUtils.convertDateTimeToEpoch(data[0], date);   // <-- actually used
}
decodeResult.raw.message_timestamp = time;

The date local in processDateCode is exactly the same swap, with no if (isNaN(time)) retry — strongly suggesting the second convertDateTimeToEpoch call was dropped during a refactor.

Suggested fix

Either (a) restore the NaN fallback so processDateCode behaves like processTimeStamp:

function processDateCode(decodeResult: DecodeResult, data: string[]) {
  if (data.length !== 2) return;

  let time = DateTimeUtils.convertDateTimeToEpoch(data[1], data[0]);
  if (Number.isNaN(time)) {
    const swapped =
      data[0].substring(2, 4) +
      data[0].substring(0, 2) +
      data[0].substring(4, 6);
    time = DateTimeUtils.convertDateTimeToEpoch(data[1], swapped);
  }
  decodeResult.raw.message_timestamp = time;
}

…or (b) delete the unused date local entirely if the fallback is genuinely not wanted here, so the file stops carrying a misleading half-implementation. A test pair (one DDMMYY date that succeeds on the first try; one ambiguous date that needs the swap) would lock the chosen behavior in.

Related observations (same file, lower priority)

While reading I noticed two other smaller items that could be folded into the same cleanup PR or filed separately:

• FlightPlanUtils.parseHeader else branch can produce "undefined...". decodeResult.remaining.text += header; is unsafe when remaining.text is still undefined (the defaultResult() shape). In practice decodeH1Message zeroes it first so the bug isn't observable through that path, but other call sites of processFlightPlan are not protected.
• FlightPlanUtils.processFlightPlan reads data[i + 1] without bounds-checking. For an even-length data array, the final iteration sees value === undefined; cases like 'FP' (value.trim()) would then throw. Malformed input only, but worth a guard.

Happy to split those out if helpful.