https://sonarly.com/issue/21521?type=bug
The `DateTimeDisplay` component passes field values directly to `Temporal.Instant.from()` without validating they are valid ISO 8601 datetime strings, causing a `RangeError` crash when a custom object field contains non-ISO text like "JULY".
Fix: Wrapped the `Temporal.Instant.from(value)` call in a `useMemo` with a try-catch to safely handle non-ISO 8601 date strings stored in datetime fields.
**What changed:**
- Added `useMemo` import alongside existing `useContext`
- Extracted the `Temporal.Instant.from(value)` call into a memoized `instant` variable that returns `undefined` if the value is not a valid ISO 8601 instant string
- Changed the conditional render to check `instant !== undefined` instead of `isNonEmptyString(value)`
**Why this approach:**
- The `try-catch` is narrowly scoped to the specific parsing operation, not a broad error swallower — it only catches `RangeError` from `Temporal.Instant.from()` on invalid input
- Graceful degradation: when the value can't be parsed as an instant, the date text still renders (via `formatDateTimeString` which already handles invalid dates gracefully), only the timezone abbreviation is omitted
- The `useMemo` ensures the parsing only re-runs when `value` changes, matching existing patterns in sibling display components like `EmailsDisplay`, `PhonesDisplay`, and `LinksDisplay`
- This addresses the risk the original PR author (`0b5be7caa31`) explicitly called out: *"If the input is badly formatted Temporal will throw, we might want to adopt a global strategy to avoid that"*
Sonarly Claude Code
174d3ff083