`isISO8601` rejects `T24:00:00` and accepts mixed separators
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- tooling
Research direction
Start at the isISO8601 entry point and inspect how the end-of-day 24:00 alternative interacts with capture group 17 and the seconds backreference. Update the pattern so valid T24:00:00 input is accepted while mixed basic and extended formats are rejected, then run test/validators.test.js and verify all examples in the issue.
Written by the indexing model from the issue text.
Description
Describe the bug
In the isISO8601 pattern, the end-of-day alternative 24:?00 sits outside
capture group 17, which is the group the seconds backreference \17 uses to
enforce a consistent separator. As a result the 24:00 branch is exempt from
the separator rule that every other hour is subject to.
This produces wrong verdicts in both directions:
2009-01-01T24:00:00is rejected, although the test suite already asserts
that2007-04-05T24:00is valid. Adding the seconds field to a form the
project treats as valid makes it invalid.2009-01-01T240030and2009-01-01T24:0030are accepted, although they mix
the basic and extended formats, which ISO 8601 does not permit. The
equivalent mixture at any other hour is correctly rejected.
Examples
const validator = require('validator'); // 13.15.35
// Rejected, but 'T24:00' is in the valid list in test/validators.test.js
validator.isISO8601('2009-01-01T24:00:00'); // false, expected true
validator.isISO8601('2007-04-05T24:00'); // true
// Accepted, but they mix basic and extended format
validator.isISO8601('2009-01-01T240030'); // true, expected false
validator.isISO8601('2009-01-01T24:0030'); // true, expected false
// The same mixture at hour 23 is correctly rejected, which isolates the cause
validator.isISO8601('2009-01-01T23:59:59'); // true
validator.isISO8601('2009-01-01T235959'); // true
validator.isISO8601('2009-01-01T23:5959'); // false
The last three lines are the control: group 17 does its job for 23, so the
difference is the placement of the 24:?00 alternative, not the backreference
itself.
Reproductions
The Examples block above runs as-is on Node after
npm install validator@13.15.35; no harness or scaffolding needed.
Additional context
Validator.js version: 13.15.35
Node.js version: v26.7.0
OS platform: Linux
- Dominant language
- JavaScript
- Stars
- 23.7k
- Forks
- 2.5k
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from validatorjs/validator.js
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
validatorjs/validator.js#2885 ·
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
validatorjs/validator.js#2862 ·
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
validatorjs/validator.js#2861 ·
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
validatorjs/validator.js#2860 ·
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
validatorjs/validator.js#2859 ·
All issues in validatorjs/validator.js
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
sugarlabs/musicblocks#8847 ·
-
client-controller-update ta-bot-triage team-money-movement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MetaMask/metamask-mobile#36594 ·