Should DbDataReader implementations be supported that return System.Nullable<X> from GetFieldType?

https://github.com/yellowfeather/DbfDataReader currently returns DateTime? from GetFieldType. When Dapper matches this against a DateTime? constructor parameter, it first unwraps the constructor parameter type to DateTime and then requires it to match the DateTime? it got from GetFieldType.

Because typeof(DateTime) == typeof(DateTime?) fails, Dapper then proceeds to show a very confusing error message saying that did not find a constructor with a signature that matches DateTime? x, even though it did. Wouldn't it make sense to detect that the problem is not with the constructor, whether or not this is considered a bug in DbfDataReader?

I would expect Dapper to either tolerate this or provide an error message explaining that the data reader implementation is buggy, rather than saying that a constructor signature doesn't exist which does exist. Which way sounds best to you?

These are the lines that would need to be changed:

https://github.com/StackExchange/Dapper/blob/e723ceed16c0591503530dc9a7b5de5dc6b7db03/Dapper/DefaultTypeMap.cs#L81-L82

Start in Dapper/DefaultTypeMap.cs at lines 81-82 and trace how DbDataReader.GetFieldType() is matched against nullable constructor parameters. Decide whether the mapping should tolerate System.Nullable or report the data-reader mismatch, then add coverage that verifies the resulting behavior and message.