Closed kupci closed 5 years ago
Makes sense to me (even outside question of bigger changes), esp. with 2.10 essentially defaulting to "lenient" handling.
Do you think there are other data types here that should be similarly changed?
I went ahead and merged this in master
, backported in 2.10: I think that in short term, this makes sense. If we can come up with more general, consistent scheme for 3.0, that'd be nice, but for now I think this will work better than it used to.
Do you think there are other data types here that should be similarly changed?
Yes, it certainly looks so. The same "empty string" test case that was in this fix also exposes the issue in the rest of the deserializers, except for the ones that were part of this fix, and YearDeserializer.
I've added issue #138 for this.
Ok cool. Now we have a template sort of, as well as current definition. I'll try to get as many PRs as possible merged for 2.10, and I think that they can be done as patches too since "lenient" is still the default for 2.10.
If 'strict', treat empty string as invalid format, so that LocalDateDeserializer and LocalDateTimeDeserializer report this as an error instead of mapping to null. See issue #114