`isISO8601` rejects `T24:00:00` and accepts mixed separators

Open Beginner friendly
#2,858 0 comments 0 reactions 0 assignees View on GitHub

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

🐛 bug

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:00 is rejected, although the test suite already asserts
    that 2007-04-05T24:00 is valid. Adding the seconds field to a form the
    project treats as valid makes it invalid.
  • 2009-01-01T240030 and 2009-01-01T24:0030 are 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from validatorjs/validator.js

All issues in validatorjs/validator.js

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.