Skip to content

fix(utils): return original input from date formatters on invalid dates - #6249

Open
Arunendra21 wants to merge 1 commit into
simstudioai:stagingfrom
Arunendra21:fix-invalid-date-formatters
Open

fix(utils): return original input from date formatters on invalid dates#6249
Arunendra21 wants to merge 1 commit into
simstudioai:stagingfrom
Arunendra21:fix-invalid-date-formatters

Conversation

@Arunendra21

@Arunendra21 Arunendra21 commented Aug 4, 2026

Copy link
Copy Markdown

Summary

formatCompactTimestamp and formatAbsoluteDate in packages/utils/src/formatting.ts build their output from Date getters. An unparseable string produces an Invalid Date whose getters return NaN rather than throwing, so formatCompactTimestamp returned "NaN-NaN NaN:NaN" (its try/catch fallback never ran, since nothing throws) and formatAbsoluteDate returned the literal "Invalid Date".

Both now check Number.isNaN(date.getTime()) up front and fall back to the original input string, which is what the existing catch was already meant to do. Valid dates are unaffected.

Type of Change

  • Bug fix

Testing

Verified both functions against valid and invalid inputs. Updated the existing formatCompactTimestamp invalid-date test to assert the returned value (it previously only checked typeof result === 'string', so the "NaN-NaN NaN:NaN" output slipped through), and added a matching invalid-date test for formatAbsoluteDate.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

formatCompactTimestamp and formatAbsoluteDate both build their output
from Date getters. An unparseable string produces an Invalid Date whose
getters return NaN rather than throwing, so formatCompactTimestamp's
try/catch fallback never ran and it returned "NaN-NaN NaN:NaN", while
formatAbsoluteDate returned the literal "Invalid Date".

Both now check Number.isNaN(date.getTime()) up front and fall back to the
original input string, which is what the existing catch was meant to do.
Valid dates are unaffected.

Updates the formatCompactTimestamp invalid-date test to assert the
returned value instead of only its type, and adds a matching test for
formatAbsoluteDate.

Co-authored-by: eeshsaxena <eeshsaxena@gmail.com>
@vercel

vercel Bot commented Aug 4, 2026

Copy link
Copy Markdown

@Arunendra21 is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

@cursor

cursor Bot commented Aug 4, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Small display-only bug fix in shared formatters; behavior for valid dates is unchanged and risk is limited to how bad date strings appear in the UI.

Overview
formatAbsoluteDate and formatCompactTimestamp now treat unparseable strings as invalid dates and return the original input instead of "Invalid Date" or "NaN-NaN NaN:NaN".

Invalid Date values do not throw, so formatCompactTimestamp’s existing try/catch never ran; both helpers add an explicit Number.isNaN(date.getTime()) guard before formatting. Valid inputs are unchanged.

Tests assert the fallback for not-a-date (including that compact output does not contain NaN).

Reviewed by Cursor Bugbot for commit 375dbb8. Bugbot is set up for automated code reviews on this repo. Configure here.

@greptile-apps

greptile-apps Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR makes two date formatters return their original input when parsing produces an invalid date.

  • Adds explicit Invalid Date checks to formatAbsoluteDate and formatCompactTimestamp.
  • Strengthens invalid-input tests for both formatters.
  • Leaves the newly introduced fallback behavior undocumented in their return contracts.

Confidence Score: 4/5

The PR appears safe to merge, with only a non-blocking documentation mismatch around the new fallback contract.

The invalid-date guards and tests correctly implement the intended behavior; only the exported functions' return documentation remains inconsistent with that behavior.

Files Needing Attention: packages/utils/src/formatting.ts

Important Files Changed

Filename Overview
packages/utils/src/formatting.ts Adds correct invalid-date guards to both formatters, but their TSDoc still promises only fixed formatted output.
packages/utils/src/formatting.test.ts Adds precise assertions that invalid inputs are returned unchanged and malformed NaN output is avoided.

Reviews (1): Last reviewed commit: "fix(utils): return original input from d..." | Re-trigger Greptile

Comment on lines +108 to +110
// "Invalid Date"; fall back to the original input instead.
if (Number.isNaN(date.getTime())) {
return dateString

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Document the fallback contract

Both exported functions now return the original input for invalid dates, but their TSDoc still promises a formatted date string. Documenting this fallback prevents consumers from incorrectly assuming that every result conforms to the advertised fixed date format.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant