changed enitre logic for isIso8601 and it's test cases#2564
changed enitre logic for isIso8601 and it's test cases#2564jesroffrouk wants to merge 5 commits intovalidatorjs:masterfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2564 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 114 114
Lines 2535 2551 +16
Branches 641 644 +3
=========================================
+ Hits 2535 2551 +16 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@rubiin can you please review this PR ? |
WikiRik
left a comment
There was a problem hiding this comment.
One quick comment to resolve the warning from codecov.
Also; this is a breaking change and it might be a while before we merge this. #2398 is also likely to be part of the next major release
@profnandaa is in charge of deciding when we want to go ahead with a new major release
src/lib/isISO8601.js
Outdated
| const UTCday = d.getUTCDay(); | ||
| // ISO weeks: week starts on Monday (1), ends Sunday (7) | ||
| // Dec 31 must be Thursday (4) or it's a leap year ending on Wednesday (3) | ||
| return UTCday === 4 || (UTCday === 3 && isLeapYear(year)); |
There was a problem hiding this comment.
This line is partially covered by the tests, can you see if you can add additional tests for this?
There was a problem hiding this comment.
Done. I have also corrected some of the logic
|
Thanks for the heads-up! I’ll look forward to the Codecov warning soon. |
changed logic for has53week
|
@profnandaa Could you please share an approximate timeline for the next major release? If it's going to take some time, I’ll go ahead and fix the current issue #2003 with minimal tweaks. Otherwise, I can wait and align with the upcoming release. |
feat(isISO8601): Rewrote entire logic for isISO8601 to solve the issue of #2003
I rewrote the entire logic for isISO8601 to fix several unhandled edge cases and improve overall reliability. Specifically, this addresses:
Week-based date formats (e.g. 2023-W52-7)
Milliseconds without seconds (e.g. 2023-03-15T13:30.123Z)
Incorrect acceptance of dates like 2016-W53 due to regex-only checks
This also resolves #2003.
Key changes:
Removed strict and strictSeparator options, as they don’t align with ISO 8601:2019, which mandates the 'T' separator.
Consolidated validation into a single regex, followed by actual date component checks (rather than relying on regex to determine validity).
Added comprehensive handling for leap years, week formats, time zones, and date boundaries.
Skipped support for astronomical years and basic format (e.g., 20251231) — these can be added later if needed, but are uncommon in modern usage.
The updated validator now handles all extended ISO 8601 formats I could find and passes against a wide range of edge cases.
References:
Checklist