For continuous values that are integers, it is possible to have max and min values where the max value is greater than the min value (so isn't caught by fix for issue #40 Add validation for min must be less than or equal to max) but where there is no valid value between the max and min; this is only possible when both max and min use exclusive comparisons (e.g. greater than rather than greater than or equal to). For instance, the following is currently treated as valid but in fact there are no values that meet this condition:
The same situation is possible for datetimes because, although time is continuous, we limit the allowed datetime formats. In the case where the datetimes are fully specified down to seconds (the most granular datetime format we allow), and the comparisons are both exclusive, we can again enter inputs that allow NO valid values but still pass validation:
Note that this issue does NOT affect decimals (unless you get to the limits of precision stored in the computer, which seems pretty unlikely) since you can always add another decimal place in order to create a value that falls between two arbitrary decimals (e.g., if min > 1.345 and max < 1.346, then 1.3455 is a valid value that we can really provide).
For continuous values that are integers, it is possible to have max and min values where the max value is greater than the min value (so isn't caught by fix for issue #40 Add validation for min must be less than or equal to max) but where there is no valid value between the max and min; this is only possible when both max and min use exclusive comparisons (e.g. greater than rather than greater than or equal to). For instance, the following is currently treated as valid but in fact there are no values that meet this condition:
The same situation is possible for datetimes because, although time is continuous, we limit the allowed datetime formats. In the case where the datetimes are fully specified down to seconds (the most granular datetime format we allow), and the comparisons are both exclusive, we can again enter inputs that allow NO valid values but still pass validation:
Note that this issue does NOT affect decimals (unless you get to the limits of precision stored in the computer, which seems pretty unlikely) since you can always add another decimal place in order to create a value that falls between two arbitrary decimals (e.g., if min > 1.345 and max < 1.346, then 1.3455 is a valid value that we can really provide).