fix: syntax error with datetime fields and standardize date/datetime formats#3698
fix: syntax error with datetime fields and standardize date/datetime formats#3698
syntax error with datetime fields and standardize date/datetime formats#3698Conversation
|
@maximepvrt is attempting to deploy a commit to the Nuxt Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThis PR extends the people data collection schema with two new date-related fields and implements formatting utilities to support them. A new Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
commit: |
|
@Joehoel This PR should resolve the issue, I would appreciate if you can verify using |
Testing fix for datetime fields syntax error. Uses pkg.pr.new build: https://pkg.pr.new/@nuxt/content@3698 Ref: nuxt/content#3698 (comment)
|
@farnabaz If you prefer using an ISO datetime format like I can also look into removing the dependency on |
|
Thanks for the PR @maximepvrt, |
@farnabaz Could you clarify which datetime format we should officially validate for Nuxt Content? Should we use ISO with the T separator? If so, we’ll need a transformer for Postgres timestamps to produce this format, but I’m not sure how to implement it. |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@src/utils/content/transformers/utils.ts`:
- Around line 8-24: The date/time functions formatDateTime and formatDate use
local-time getters causing timezone-dependent shifts; replace
getHours/getMinutes/getSeconds/getFullYear/getMonth/getDate with their UTC
equivalents (getUTCHours, getUTCMinutes, getUTCSeconds, getUTCFullYear,
getUTCMonth, getUTCDate) in formatDateTime and formatDate so parsing of ISO
dates (e.g., "2024-01-15") yields consistent UTC-based output; keep the same
string padding and formatting logic but derive
year/month/day/hours/minutes/seconds from the UTC getters and remember to add 1
to getUTCMonth as before.
- Line 9: Validate the Date created from new Date(datetime) in the utils.ts
transformer utilities: after the existing const d = new Date(datetime) (and the
other occurrence at the second new Date call), check Number.isNaN(d.getTime())
and throw a TypeError with a clear message like `Invalid date value: "<input>"`
when invalid; update both places where new Date(datetime) is used so downstream
getters won't produce NaN values and SQL errors.
- Line 1: Remove the unused import from `@internationalized/date` in
src/utils/content/transformers/utils.ts — the symbols fromDate,
toCalendarDateTime, toCalendarDate, and getLocalTimeZone are no longer used
after switching to native Date; delete that import line and any references to
those symbols (if any) such as in functions that previously relied on them
(e.g., transformer helpers in this file), and also remove
`@internationalized/date` from package.json dependencies to avoid pulling the ~1MB
package into CI.
I think your current implementation is great, and |
|
It's perfect ! Just making sure we're aligned on the format |
This PR addresses two separate improvements:
Standardize date/datetime formats
YYYY-MM-DDYYYY-MM-DD HH:mm:ssThese are the default storage formats for dates in databases, ensuring consistent behavior across queries.