Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughThis change introduces a new date formatting utility function and updates components to use consistent date formatting. A new 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| try { | ||
| return new Date(date).toLocaleDateString('en-US', { | ||
| year: 'numeric', | ||
| month: 'short', | ||
| day: 'numeric', | ||
| }) | ||
| } catch { |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
JavaScript new Date('invalid').toLocaleDateString() behaviour throw exception or Invalid Date
💡 Result:
new Date("invalid") creates a Date object whose internal time value is NaN (an “Invalid Date”).
For toLocaleDateString(), the ECMAScript Internationalization (ECMA‑402) spec says:
- If the Date’s internal time value is
NaN, return the string"Invalid Date"(no exception). [1]
So:
new Date("invalid").toLocaleDateString() // "Invalid Date"When you do see an exception with date formatting APIs, it’s typically a RangeError due to invalid locales/options (e.g., an invalid timeZone), not because the Date is invalid. [1]
(Separately: toISOString() does throw on an invalid date, which is a different method and behavior.) [2]
Sources: [1] [2]
🌐 Web query:
JavaScript Date.toLocaleDateString() timezone day shift date-only strings timeZone UTC
💡 Result:
Date.prototype.toLocaleDateString() formats the same instant in time in whatever time zone you tell it (default: the user’s local time zone). If that instant crosses midnight in that zone, the calendar day can shift. (developer.mozilla.org)
Why it happens with date-only strings ("YYYY-MM-DD")
In JavaScript, an ISO date-only string like "2026-03-03" is parsed as UTC midnight (2026-03-03T00:00:00.000Z). (stackoverflow.com)
If you then format it in a negative-offset time zone (e.g., America/Los_Angeles), that UTC midnight is still the previous local evening, so the displayed date becomes the day before. (developer.mozilla.org)
const d = new Date("2026-03-03"); // 2026-03-03T00:00:00.000Z (UTC)
d.toLocaleDateString("en-US"); // may show 3/2/2026 in US time zones west of UTC
d.toLocaleDateString("en-US", { timeZone: "UTC" }); // 3/3/2026Fixes (pick based on what your string means)
- If the string is a UTC date (common for APIs): format in UTC
new Date("2026-03-03").toLocaleDateString("en-US", { timeZone: "UTC" });timeZone is an Intl.DateTimeFormat option used by toLocaleDateString. (developer.mozilla.org)
- If the string is a “local calendar date” (e.g., user picked March 3): construct it as local midnight (avoid ISO-string parsing)
const [y, m, d] = "2026-03-03".split("-").map(Number);
new Date(y, m - 1, d).toLocaleDateString("en-US"); // won’t shift by timezone- If you must keep it ISO but want consistent display: store/transport an ISO date-time with an explicit offset (e.g.,
Zor-05:00) rather than date-only strings. (stackoverflow.com)
Citations:
- 1: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString?utm_source=openai
- 2: https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results?utm_source=openai
- 3: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString?utm_source=openai
- 4: https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString?utm_source=openai
- 5: https://stackoverflow.com/questions/2587345/why-does-date-parse-give-incorrect-results?utm_source=openai
🏁 Script executed:
cd app/utils && cat -n formatters.ts | head -25Repository: npmx-dev/npmx.dev
Length of output: 705
Stabilise date parsing and timezone to prevent incorrect published dates.
The try/catch fallback is ineffective: invalid dates do not throw exceptions—toLocaleDateString() returns the string "Invalid Date" instead. Additionally, ISO date-only strings (e.g. "2026-03-01") are parsed as UTC midnight and will display as the previous day in western timezones unless formatted with timeZone: 'UTC'.
Proposed fix
export function toLocaleDateString(date: string): string {
if (!date) return ''
- try {
- return new Date(date).toLocaleDateString('en-US', {
- year: 'numeric',
- month: 'short',
- day: 'numeric',
- })
- } catch {
- return date
- }
+ const parsed = new Date(date)
+ if (Number.isNaN(parsed.getTime())) return date
+
+ return parsed.toLocaleDateString('en-US', {
+ year: 'numeric',
+ month: 'short',
+ day: 'numeric',
+ timeZone: 'UTC',
+ })
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| try { | |
| return new Date(date).toLocaleDateString('en-US', { | |
| year: 'numeric', | |
| month: 'short', | |
| day: 'numeric', | |
| }) | |
| } catch { | |
| export function toLocaleDateString(date: string): string { | |
| if (!date) return '' | |
| const parsed = new Date(date) | |
| if (Number.isNaN(parsed.getTime())) return date | |
| return parsed.toLocaleDateString('en-US', { | |
| year: 'numeric', | |
| month: 'short', | |
| day: 'numeric', | |
| timeZone: 'UTC', | |
| }) | |
| } |
|
oops - merged #1891 - but it looks like you also have some more fixes - would you mind resolving conflicts once that merges? 🙏 |
|
Fix already inplemented in #1891 |
2 participants
🔗 Linked issue
Partially resolves #1887
📚 Description
Format date of blog in blog post list to human-friendly format.