Use Number.isNaN instead of global isNaN for type safety

[pavankumar-vh]

Overview

Fix type safety issue in common/src/util/log-ingest.ts by using Number.isNaN instead of the global isNaN function.

Bug Description

The global isNaN() function coerces non-numbers to numbers first, which can lead to unexpected results. For example, isNaN('hello') returns true because 'hello' is coerced to NaN, but Number.isNaN('hello') returns false because 'hello' is not a number type.

Fix

Changed isNaN(ts.getTime()) to Number.isNaN(ts.getTime()) for more predictable and safer type checking.

Testing

No existing tests for this function, but the fix improves type safety.

Files Changed

• common/src/util/log-ingest.ts - Use Number.isNaN instead of global isNaN

Scope

This change only touches common/ which is an approved contribution area per the Contributing Guide.

[codebuff-team]

Good, minimal, focused change. ts.getTime() always returns a number (or NaN), so in this specific case isNaN and Number.isNaN behave identically today - there's no coercion risk since the argument is already a number. That means this isn't fixing an active bug, but it is a correct defensive improvement and matches common lint rules (e.g. no-implicit-coercion / unicorn/prefer-number-properties) that many codebases enforce. Worth porting as a small hygiene fix.

One nit: the PR description overstates the bug (isNaN('hello') example isn't actually applicable here since the input is always a Date.getTime() result), so it reads a bit AI-generated in its justification. Keep future PR descriptions tied to the actual behavior at the call site rather than generic examples - that will build more trust with reviewers.

No tests needed for a one-line safe swap like this. Fine as-is.