Fix #364: make one-based Month deserializer accept "12" #365
Conversation
| if (zeroBaseMonth == Month.JANUARY) { | ||
| throw new InvalidFormatException(parser, "Month.JANUARY value not allowed for 1-based Month.", zeroBaseMonth, Month.class); | ||
| if (_isPossibleNumericValue(token)) { | ||
| String monthSpec = parser.getText(); |
There was a problem hiding this comment.
Ideally this should not use getText() if we get actual number (JsonToken.VALUE_NUMBER_INT) but just call parser.getIntValue().
There was a problem hiding this comment.
Agreed, reworked in 3f564fa
|
First of all: thank you for reporting the issue and providing a fix! It looks good overall. But one thing we need before merging (if not done earlier): we'd need CLA (from here: https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf ). The usual way is to print it, fill & sign, email to Once we have it, we can proceed with merging. Thanks again! |
|
CLA received: hoping to review and merge this weekend. |
As described in #364 ,
com.fasterxml.jackson.datatype.jsr310.deser.OneBasedMonthDeserializerincorrectly assumed that all values can be converted to aMonthvalue by the original deserializer. This assumptions fails for"12".In this fix the
OBMDis refactored in order to depend less on the original deserializer. Certain inputs (1-digit and 2-digit numbers and their string representations) are handled - validated and parsed - directly. Non-numeric inputs as well as numbers that have 3 or more digits are forwarded to the delegate, as before.Associated tests are expanded to cover all months.