I'd disagree. My view is that it is perfectly acceptable for an API (a programming interface) to work that way - and it's understandable why it does. But /programmers/ are expected to read API documentation and then make use of the interfaces appropriately. Here, I'd expect that (if, as it seems, timestamps are tested not just day numbers) that "after date" should be treated as "greater than daynumber.999999" (to whatever precision FM's system records fractional days) rather than "greater than daynumber.000000". That is, I'd view this as an error in translating a parameter specified in a user interface into what's required for the programming interface. (Lots of things commonly need translated back and forth between external user-facing representations and internal forms; this is not unusual.)
Users on the other hand are not expected to (need to) understand anything about the underlying architecture. There is, in my view, no good reason why a search that specifies "after a date" should not mean exactly what it does in everyday life. If I say I'll do something "after Wednesday" I would not expect anybody to think I might start on Wednesday.
Moreover, FM's GUI search interface lacks immediately visible documentation. There's no indicator that "after" might not be intuitive, and no link to a help page. So no normal user is ever going to find their way to the documentation, such as it is. Currently the search help page says nothing at all about "after date" meaning "after the first nanosecond of that day".
There's a principle, "least astonishment", that's used in some programming languages and in interface design - see:
https://en.wikipedia.org/wiki/Princi...t_astonishment - in which interfaces are meant to be designed so that they'll do what most users would expect. My view would be that this feature violates that principle.