Regex Constraint ISO 8601 Produces False Results
🐛 Bug Report
New: See commentary below!
Summary
The regular expression constraint for ISO 8601 date validation does not correctly detect invalid or missing date values. The bug occurs only sporadically, but leads to false positives when it does (see "Additional context"). Non-ISO-compliant dates and completely missing values both produce false positives. At the same time, valid ISO 8601-compliant date strings (e.g., 2024-06-10T09:52:21.658) are sometimes falsely marked as incidents.
Steps to Reproduce
-
Define a constraint on the basis of the variant: For each all match the ISO 8601 format.
-
Provide one or more of the following: Invalid date: 20250832 Incorrect format: 25-08-2025 Empty value / no date provided Valid ISO 8601 value: 2024-06-10T09:52:21.658
-
Run the quality analysis
-
Observe that the report sometimes remains green even for invalid or missing dates. Sometimes valid values are flagged incorrectly as incidents.
What is the current bug behavior?
Invalid dates do not trigger errors.
Completely missing date values still result in a green check instead of a neutral "Zero Findings".
What is the expected correct behavior?
Only valid ISO 8601 date strings should pass the check.
Missing values should not be treated as passing, but should result in "Zero Findings".
Valid values like 2024-06-10T09:52:21.658 must always be accepted as correct.
Relevant Logs, Screenshots, or Gifs
Possible Fix or Suggested Solution
Ensure the regex actually matches ISO 8601 valid formats.
Additional Context
The time specification <lido:recordMetadataDate lido:type=“http://terminology.lido-schema.org/recordMetadataDate_type/created”>2024-06-10T09:52:21658</lido:recordMetadataDate> is recognized as non-ISO compliant. However, lido:earliestDateAugust 12, 2019</lido:earliestDate> instead of lido:earliestDate2019-08-12</lido:earliestDate> is not recognized as an error.
This issue is structurally similar to previously reported problems with ASCII and ISIL regex patterns: #85