Additional check for QualificationValue

[apetushok]

for #98

[apetushok]

I have verified that both characters are valid and are used to display the date. So this simple check should be enough.

[mzeinstra]

They are valid components but they are not valid when used together.

See https://www.loc.gov/standards/datetime/

the uncertain and approximate qualifiers, '?' and '~', when applied together, are combined into a single qualifier character '%';

So it seems that you can only have one character to denote the certainty.

[JeroenDeDauw]

@mzeinstra so an input such as 1950?~ should be treated as invalid? Or as if it was 1950% ?

Either way, this PR should add a test that verifies the new behavior for 1950?~ @apetushok

[mzeinstra]

Depending how strict we want to be 1950?~ or 1950~? and essentially not valid values, we can automattically transform them to 1950%, but is that expected behaviour by the users of this tool?

Either it should transform the string or it should throw an error in my opinion. I am leaning a bit to throwing an error as that is more clean than chaning user inputted values.

[apetushok]

Thanks @mzeinstra.
Since there is such support according to the specification #100 (comment)
I think it makes sense for us to add it too.

cc @JeroenDeDauw

[mzeinstra]

Thanks @mzeinstra. Since there is such support according to the specification #100 (comment) I think it makes sense for us to add it too. cc @JeroenDeDauw

Not entirely true, there are not examples on that page that combine ? and , either ? or ?. So while % means that both the qualifiers ? and ~ apply does not mean that ? in a string is valid.

[apetushok]

I think you're right. Seems like the best solution here is to throw an error

[apetushok]

Fixed