date validation sometimes allows invalid February 29 dates

[ElectricNroff]

Following up on the #817 issue, February 29 is sometimes accepted when the year is not a leap year:

/cve-id?time_reserved.gt=2100-02-29T00:00:00Z
==>
{"cve_ids":[]}

/cve-id?time_reserved.gt=2099-02-29T00:00:00Z
==>
Bad date, or invalid timestamp format: valid format is yyyy-MM-ddTHH:mm:ss or yyyy-MM-ddTHH:mm:ss.ZZZZ

but 2100-02-29 is equally bad because 2100 is not a leap year:
anveshkolluri93/validate-date#4

[slubar]

The dates above return empty lists because there are no CVE IDs for 2099 or 2100. If the endpoint is called with the timestamp 2022-02-29T00:00:00Z, an invalid timestamp error is thrown

[ElectricNroff]

The envisioned desired behavior is that a time_reserved.gt=2100-02-29T00:00:00Z request should return an error, and should not cause the application to look for anything in the Cve-Id collection. (It is possible that, in March 2100, someone would have reserved a new CVE-2023-xxxxx ID.) The day 2100-02-29 does not exist (most years divisible by four will be leap years, but 2100 won't be a leap year). You can also WONTFIX this issue because there are no known use cases for 2100. Realistically, it would only affect users who deploy their own copy of the cve-services application and decide to advance the clock on their server to more than 70 years in the future.

[anveshkolluri93]

@ElectricNroff The underlying issue in validate-date library has been fixed. Please, upgrade and retry. Thanks!

Pull Request