Are you enclosing the search term in quotes, as you seem to have done here? You don't need to.
Is the field in question defined as type Timestamp?
Does your system use the U.S. date format (month/day/year)? If so, we haven't gotten to August yet.
Having you're wildcard in the quotes is preventing it from working
Using both later than operator and wild card not make sence.
If you want to find after the timestamp,
If you want to find exact the day in the second, ignoring fraction
>=08/04/2016 will default to ALL times that date and forward. If you Modify last find, you will see that FM has added the *:*:* to the time part.
I agree. No quotes and no wildcard needed - FM will add as needed for you. Especially since you have greater than or equal ≥ or >= symbols.
If your timestamp searches are on-going you could use another approach that eliminates going into find mode. Create a new table called timestamp_find with 2 fields. One field is just a global timestamp field where you will enter what you would normally put in a find request, and a second field to count the related records. Create a timestamp_find <=main file modification timestamp field relationship. On the layout of your new table put a portal to include whatever fields are pertinent, plus the count field. Then enter 8/4/2016 13:14:52 in the global to see if those 100-plus records show up in the portal. If you are not able to capture all the fields you need to see, or update, in the portal, you could add a button that goes to the Related Records (Match current record only since your new table only needs 1 record) in a new window that does not disturb the full set in the main file.
You haven't said the reason for the timestamp search, but if you have to do it frequently the above approach may be useful.