Right now, if you want to check if a date is smaller dan another one, you must include ‘AND Date <> Empty”, because an empty date is not empty, but contains a date way back in history.
This is not very intuitive and forces us to include more checks than necessary (in my opinion at least).
Could you change that?
Hello,
An empty date really is empty, it’s just that we treat it as the smallest possible date as well for comparisons. I see that you likely have some experience querying databases since you used the <> notation, but most of our user don’t. So a long time ago we needed to decide what to do with empty values and we decided to step away from how SQL and the likes work, and instead sought for a way that non-technical users would understand better. What for example should be the result of adding 1 to nothing? In SQL the result will be NULL, but if you have no experience with SQL, the more intuitive result is that the outcome is 1. Therefore it also makes sense that “nothing” is smaller than 1. For consistency, we applied the same thing to dates, so users can apply what they’ve learned to all places where they can use larger-than and smaller-than operators.
That does indeed mean that you need to make the additional “date is not empty” check if you only want dates that are filled in and smaller than the date you’re comparing it with. We will evaluate your proposal as we do with all suggestions made here, but please now that this is not a small change, as it means that people will need to update their comparisons in hundreds of applications and that for many people, it will likely be less intuitive.
Hello,
Thank you for your elaboration on this subject. I understand your logic partially (for me an empty date should be empty and not very small: if I check for a ‘smaller’ date I never would include the possibility of the presence of a very small date somewhere down below that symbolizes ’empty’).
I don’t understand that, if you should decide to implement the feature, all existing flows have to be modified: checking for an empty date will not harm the new function, it merely will be redundant, I think.
Nevertheless: I understand that would be quite a change.
Yes, I think you’re correct in that it would simply be redundant in a lot of cases. Still, since people built their applications with the current logic in mind, a bunch would need to add an “OR date = Empty” to their rules to get the same results. And I would definitely run it passed our testing team to see if there are any edge cases that we didn’t think of just now 
This has been implemented in the latest release. Empty dates are now smaller than any other dates.