fix(utils): resolve Safari date parsing issue by normalizing ISO strings#874
fix(utils): resolve Safari date parsing issue by normalizing ISO strings#874messiawrq-design wants to merge 1 commit into
Conversation
|
@messiawrq-design is attempting to deploy a commit to the ritesh Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughThis PR improves the ChangesDate Parsing Compatibility
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add 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 Warning |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Frontend/src/utils/dateUtils.js`:
- Around line 16-18: formatTimelineDate currently checks dateStr.includes('+')
which misses negative offsets and leads to invalid timestamps; update the
detection to test for a proper timezone suffix pattern (either 'Z' or a ±HH:MM
offset) using a regex like /(Z|[+-]\d{2}:\d{2})$/ on the trimmed dateStr before
deciding to append 'Z' so you only append 'Z' when no explicit timezone is
present (locate the logic in formatTimelineDate and replace the includes('+')
check with this regex test).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ded2e153-af4d-468f-bd38-0b61bb141b94
📒 Files selected for processing (1)
Frontend/src/utils/dateUtils.js
| if (!dateStr.includes('Z') && !dateStr.includes('+')) { | ||
| // If it's a raw string without TZ, assume it was intended as UTC from our backend | ||
| date = new Date(dateStr + 'Z'); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In JavaScript Date parsing (ECMAScript / MDN), are ISO-8601 strings with negative offsets like 2026-05-31T10:00:00-05:00 valid, and would appending Z to them make them invalid or change meaning?
💡 Result:
In JavaScript, ISO-8601 strings with a negative timezone offset, such as 2026-05-31T10:00:00-05:00, are valid and correctly parsed by the Date constructor and Date.parse [1][2][3]. Appending a Z to an ISO-8601 string that already includes a timezone offset is technically invalid according to the ECMAScript specification for date time strings [4]. While some lenient parsers might ignore the extra suffix, it is generally considered an invalid date format in JavaScript and will frequently result in an Invalid Date (NaN) [1][4][5]. Regarding meaning, the Z suffix explicitly denotes UTC (Coordinated Universal Time) [2][6][7]. If a string includes both a timezone offset (e.g., -05:00) and the Z suffix, the presence of conflicting timezone information renders the string ambiguous or invalid [4]. For clear and robust code, you should either use the offset to represent local time relative to UTC or use the Z suffix to represent absolute UTC time, but never both in the same string [2][3].
Citations:
- 1: https://devdoc.net/web/developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/parse.html
- 2: https://musatov.com/posts/iso-date-string-parsing/
- 3: https://jsonic.io/guides/json-date-handling
- 4: https://learn.microsoft.com/en-us/openspecs/ie_standards/ms-es3/79e429c6-8d02-422b-ac7a-7e18b5892eaf
- 5: https://stackoverflow.com/questions/57341057/new-date-from-iso-8601-throws-invalid-date
- 6: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString
- 7: https://www.iso8601.com/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Print the relevant section with line numbers
nl -ba Frontend/src/utils/dateUtils.js | sed -n '1,120p'Repository: ritesh-1918/HELPDESK.AI
Length of output: 110
🏁 Script executed:
#!/bin/bash
set -euo pipefail
ls -la
test -f "Frontend/src/utils/dateUtils.js" && echo "Found: Frontend/src/utils/dateUtils.js" || (echo "Missing file"; exit 1)
# Show only the relevant portion (around the reported line range)
cat -n Frontend/src/utils/dateUtils.js | sed -n '1,120p'Repository: ritesh-1918/HELPDESK.AI
Length of output: 4129
🏁 Script executed:
node <<'NODE'
const inputs = [
'2026-05-31T10:00:00-05:00',
'2026-05-31T10:00:00-05:00Z',
'2026-05-31T10:00:00+02:00',
'2026-05-31T10:00:00+02:00Z',
'2026-05-31 10:00:00-05:00', // not matching existing replace regex, but included for contrast
];
for (const s of inputs) {
const d = new Date(s);
console.log(s, '=>', d.toString(), 'time:', d.getTime());
}
NODERepository: ritesh-1918/HELPDESK.AI
Length of output: 509
Handle negative timezone offsets before appending Z in formatTimelineDate. [major issue]
dateStr.includes('+') misses valid ISO offsets like -05:00, so the code appends Z and produces an invalid timestamp (new Date("...-05:00Z") → Invalid Date). Update timezone detection to explicitly match Z or ±HH:MM suffix.
Proposed fix
- if (!dateStr.includes('Z') && !dateStr.includes('+')) {
+ const hasTimeZone = /(?:Z|[+-]\d{2}:\d{2})$/i.test(dateStr);
+ if (!hasTimeZone) {
// If it's a raw string without TZ, assume it was intended as UTC from our backend
date = new Date(dateStr + 'Z');
} else {
date = new Date(dateStr);
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Frontend/src/utils/dateUtils.js` around lines 16 - 18, formatTimelineDate
currently checks dateStr.includes('+') which misses negative offsets and leads
to invalid timestamps; update the detection to test for a proper timezone suffix
pattern (either 'Z' or a ±HH:MM offset) using a regex like
/(Z|[+-]\d{2}:\d{2})$/ on the trimmed dateStr before deciding to append 'Z' so
you only append 'Z' when no explicit timezone is present (locate the logic in
formatTimelineDate and replace the includes('+') check with this regex test).
|
Hi @messiawrq-design! 🙌 Thank you so much for your excellent contribution: "fix(utils): resolve Safari date parsing issue by normalizing ISO strings"! We really appreciate the high-quality code and effort you have put into the platform. Just a quick, friendly heads-up as we prepare our manual merging and verification queues—please make sure to complete all the mandatory community steps listed below. Once those manual steps are verified, we'll get your PR officially merged into the Let's build something amazing together! 🚀🔥 🌟 Community Support & Network Steps (Take 10 Seconds!)As we prepare our manual verification and merging queues, please make sure you have taken a moment to complete these required steps to finalize your points:
Note: Having these steps completed manually is required before your PR points are officially cleared. |
ritesh-1918
added
gssoc
|
Hi @messiawrq-design! 🙌 Thank you so much for your excellent contribution: "fix(utils): resolve Safari date parsing issue by normalizing ISO strings"! We really appreciate the high-quality code and effort you have put into the platform. Just a quick, friendly heads-up as we prepare our manual merging and verification queues—please make sure to complete all the mandatory community steps listed below. Once those manual steps are verified, we'll get your PR officially merged into the Let's build something amazing together! 🚀🔥 🌟 Community Support & Network Steps (Take 10 Seconds!)As we prepare our manual verification and merging queues, please make sure you have taken a moment to complete these required steps to finalize your points:
Note: Having these steps completed manually is required before your PR points are officially cleared. |
2 participants
Description
This PR fixes the ticket timeline date parsing discrepancies observed on older Safari browsers, as outlined in #642.
Changes Made:
Frontend/src/utils/dateUtils.jsto normalize incoming date strings by converting space-separated formats (YYYY-MM-DD HH:MM:SS) into strict ISO-8601 strings (using aTseparator) before passing them to the nativeDateconstructor. Safari historically returnsInvalid Datefor timestamps missing theTseparator.Related Issues
Closes #642
Payout Address (Solana):
6sF8p22Gg83NKTJ6dvya7Srv4USCniZnP47DwQwK7MtpSummary by CodeRabbit