Bug: arinc_702_helper.processDateCode computes a swapped DDMMYY→MMDDYY date and then never uses it (likely missing NaN fallback)
bug
## 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`
```ts
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):
```ts
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`:
```ts
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.
0 条评论