Fix always lenient calendar parsing/unparsing#1359
Conversation
- we used to override the leniency regardless of what the calendar check policy was, now this ticket fixes that by setting it based on the isLenient value of calendar. - uncomment previously failing tests - make newly failing tests lax - add additional test DAFFODIL-2951, DAFFODIL-1042
stevedlawrence
left a comment
stevedlawrence
left a comment
There was a problem hiding this comment.
Change seems reasonable, but it looks like the existing tests already failed, makes me wonder if this does already work as expected? What does change formatter.setLenient actually change?
| <tdml:error/> | ||
| <tdml:error>Unable to parse</tdml:error> | ||
| <tdml:error>2001-03-35</tdml:error> | ||
| <tdml:error>valid range</tdml:error> |
There was a problem hiding this comment.
It looks like this tests already failed, it's just updated to include an error message. Did `calendarCheckPolicy="strict" already correctly fail to parse this in certain cases, or was the existing error something else? We had a report that this exact kind of test would successfully parse even with a strict policy.
There was a problem hiding this comment.
This test was commented out with DAFFODIL-1042. It used to work with Saxon, but failed with the new implementation
There was a problem hiding this comment.
Ah, I see now. Thanks!
I think DAFFODIL-2951 is a duplicate then. I'll close that one.
| <tdml:error/> | ||
| <tdml:error>Unable to parse</tdml:error> | ||
| <tdml:error>2001-03-35</tdml:error> | ||
| <tdml:error>valid range</tdml:error> |
There was a problem hiding this comment.
Ah, I see now. Thanks!
I think DAFFODIL-2951 is a duplicate then. I'll close that one.
3 participants
DAFFODIL-2951, DAFFODIL-1042