-
Notifications
You must be signed in to change notification settings - Fork 71
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
Bug: edtf date validation problems #1533
Comments
patdunlavey
added a commit
to Born-Digital-US/controlled_access_terms
that referenced
this issue
Jun 2, 2020
- removed extraneous commas from date set regex pattern - require at least one date string - failure to match exits, rather than continuing to parse dates - fixed bug in date part matching
seth-shaw-unlv
pushed a commit
to Islandora/controlled_access_terms
that referenced
this issue
Jun 3, 2020
- removed extraneous commas from date set regex pattern - require at least one date string - failure to match exits, rather than continuing to parse dates - fixed bug in date part matching Co-authored-by: Pat Dunlavey <pat@born-digital.com>
Resolved with Islandora/controlled_access_terms@c19f743. However, this reminds me that we really need to add some unit tests for validation, if nothing else. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A few things in EDTFUtils::validate():
[]
should not be considered a properly encoded date string, so I think the date part match group quantity should be changed from*
to+
.$has_match
is false, that's sufficient. And, we should return at this point, there's no reason to continue testing each date in the set.!$date === '..'
will never be true. Put the negation outside the expression by using parentheses.PR coming...
The text was updated successfully, but these errors were encountered: