IdParser
IdParser copied to clipboard
c0shea
Fail to parse AMVAA ID from West Virginia with 2009 spec
Apparently WV had some trouble understanding the AMVAA spec. The birthdate is written as YYYYMMDD (should be MMDDYYYY, but IdParser 3.0.4+ can handle this). But more egregiously, the "Under 18/21 Until" (DDH and DDJ) are written as MMDYYYY with no leading 0's on the day. So for a person born on November 3, 1972 the "Under 18/21 Until" fields are "DDH1131990" and "DDJ1131993". I am not sure if the month would also have a missing leading 0 as the only example I have is for someone born in November. Unfortunately setting the validation to none does not allow the rest of the data to be parsed.
It may never be possible to parse all of the wacky ways that various jurisdictions encode dates. Might it be workable to make the validation parameter more granular? Alternatively, perhaps the client could pass a list of "required" fields. All other fields would be ignored or at least parse errors for non-required fields would be ignored.
I love it when jurisdictions don't follow the standard. I never thought about the validation level outside of checking the header, but I think you're right. I added support for swallowing exceptions in the parsers when the validation level is set to none in this 65b0a20135f7b43ac43652af5ad34bb71cae5877 commit. That should allow WV to still be parsed and only have the under 18/21 fields skipped.
I'm not sure how feasible it is to add support for such a wacky aberration considering it's for fields that aren't that critical. I found a couple WV licenses in my logs that are using the 2010 spec, so I'm thinking they realized they were totally non-compliant and revised their licenses the following year. Though it's funny because they set the RevisionDate to 1/1/1753, which is the minimum value of a DateTime in SQL Server, so they still didn't get everything down right. The 2009 variants should be expiring soon if they haven't already so I don't think it's worth the effort at this point.
Thank you Connor. This will work for my needs. I was thinking that splitting the Validation into a flagged enum with "Header" and "Fields" values might give your users more flexibility. That way they could ignore errors caused by the barcode reader stripping out special characters in the header, but still require proper validation of the ID data. I'll submit a pull request if you think this is a useful way to go.
You're welcome. I'm not entirely opposed to it but I think it might be a bit involved. I would expect that if Validation.Fields is set that exceptions should be thrown if any field doesn't match the spec exactly. A number of my helper methods and parsers are currently quite lenient on what they will accept and I think you'd have to go back and undo that. I always struggle with the problem when jurisdictions don't follow the standard (and plenty of them don't in one place or more). It's usually not hard to add in a workaround to handle the cases but it does mean that it's not technically valid by AAMA, though it is valid according to the issuer. But I suppose in the end it hurts the client if they can't get at the basic fields they're looking to get. Sorry for the rant. Just not sure on the right direction of things.
I see what you mean. That does really break the contract implied by the name. So what if you were to add Validation.PermissiveFields with the expectation that you might add a Validation.StrictFields (for lack of better names) in future versions. Like I said, your current solution solves a problem for me. So take this as just musings of someone interested in your work.
FYI, the expire date in the DL that tripped this issue is set to expire in 2022. The format is 2009, but it was issued in 2017. It is the "WV License.txt" file that I added for issue #21 with altered personal info. I also removed the offending date lines so that it would only test the hair/eye color changes.