-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
changed enitre logic for isIso8601 and it's test cases #2564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2564 +/- ##
===========================================
- Coverage 100.00% 99.96% -0.04%
===========================================
Files 114 114
Lines 2535 2556 +21
Branches 641 645 +4
===========================================
+ Hits 2535 2555 +20
- Partials 0 1 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@rubiin can you please review this PR ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is partially covered by the tests, can you see if you can add additional tests for this?
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