STRATCONN-4121 - [Customerio] - fix timestamp normalization occurring after isIsoDate gate

[sydneycollins-cio]

Problem

Supersedes PR #3923. Joe Ayoub identified that the fix in #3923 lands one step too late.

In convertAttributeTimestamps, the code calls isIsoDate(value) on the original string before normalizing. isIsoDate ends with !isNaN(Date.parse(value)). In Segment's prod runtime, Date.parse returns NaN for fractional seconds longer than ~5 digits — so a 7-digit timestamp like 2024-08-14T20:36:48.6527521Z fails isIsoDate, never enters the block, and normalization is never reached. Tests in #3923 passed only because local Node accepts long fractions.

Fix

Move normalizeIsoFractionalSeconds to before the isIsoDate gate in convertAttributeTimestamps:

// Before (broken in prod runtime)
if (isIsoDate(value)) {
  ;(clone[key] as unknown) = dayjs(normalizeIsoFractionalSeconds(value)).unix()
}

// After (Joe's fix)
const normalized = normalizeIsoFractionalSeconds(value)
if (isIsoDate(normalized)) {
  ;(clone[key] as unknown) = dayjs(normalized).unix()
}

Same fix applied to convertValidTimestamp. normalizeIsoFractionalSeconds trims fractional seconds to 3 digits — no precision is lost since Unix timestamps are second-level.

Tests

Added mocked Date.parse cases that emulate Segment's prod runtime behavior (reject fractions longer than 5 digits), confirming the fix works in that environment. All 20 tests pass.

[joe-ayoub-segment]

Thanks @sydneycollins-cio approved to be deployed. Thank you!