Skip to content
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

isISO8601 doesn't support year with more than 4 digits #2262

Open
This-is-a-Book opened this issue Aug 11, 2023 · 3 comments · May be fixed by #2422
Open

isISO8601 doesn't support year with more than 4 digits #2262

This-is-a-Book opened this issue Aug 11, 2023 · 3 comments · May be fixed by #2422

Comments

@This-is-a-Book
Copy link

const iso8601 = /^([\+-]?\d{4}(?!\d{2}\b))((-?)((0[1-9]|1[0-2])(\3([12]\d|0[1-9]|3[01]))?|W([0-4]\d|5[0-3])(-?[1-7])?|(00[1-9]|0[1-9]\d|[12]\d{2}|3([0-5]\d|6[1-6])))([T\s]((([01]\d|2[0-3])((:?)[0-5]\d)?|24:?00)([\.,]\d+(?!:))?)?(\17[0-5]\d([\.,]\d+)?)?([zZ]|([\+-])([01]\d|2[0-3]):?([0-5]\d)?)?)?)?$/;

We have a code that would use maximum date possible in JS

let maxDate = new Date(8640000000000000);
let minDate = new Date(-8640000000000000);

Those would be converted to the following from toISOString() function

// maxDate
+275760-09-13T00:00:00.000Z
// minDate
-275760-09-13T00:00:00.000Z

However, when using isISO8601 validator, they're invalid because the year has more than 4 digits.

Would it be possible to fix the validator to allow year with more than 4 digits?

@Siddhant-Kashyap
Copy link

const iso8601 = /^([+-]?\d{4, }(?!\d
will puting comma after 4 work , ??

@This-is-a-Book
Copy link
Author

const iso8601 = /^([+-]?\d{4, }(?!\d will puting comma after 4 work , ??

@Siddhant-Kashyap
For my case, yes, this would work.

@pano9000
Copy link
Contributor

pano9000 commented Sep 29, 2023

I think this is intended "default" behaviour as per the standard:

but your use case also is valid, but must be handled a bit more special, when it comes to IS8601:

https://en.wikipedia.org/wiki/ISO_8601#Years

To represent years before [0000] or after [9999], the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.
An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.

And this, IMHO, should rather be something that should be done as an option, because the more common use case will be to deal with those 4 digit years - and if the RegEx is changed to also - by default - allow 4 and more digits - this will break a few validations, that depend on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants