There are a couple of ways you can deternime this.
1) When you are looking at the Receiver logs, you'll probably notice there's a small gold funnel icon in the top left corner. When you first open the log viewer, it's typically filtered to show only the "Status" events...the events with a flag. If you clear that filter (click on it, select "Show All") you'll see additional logs. The one immediately above the "Events retrieved with possible incorrect values" log should show you the problem data source.
2) If you open any view and choose a time frame that includes some time in the future ("Current Day" is often a god choice here) you should be able to quickly see what events are coming in with future time stamps.
Your first suggestion worked like a charm! As you suggested, I can confirm that the data source that generates the discarded events is mentioned in a "non-status" message.
Your second suggestion then helped me identify these events, and like I saw in another post on this subject, these messges come from "unkown events" (events not recognized by the parsing rule). It's funny that a few fields (for example, source IP, host and timestamps) in unrecognized events can still be parsed. The timestamps are in the Eastern timezone, so the ESM with its GMT timezone sees the events as being 4 hours in the future.
I identified the exact reason why this happens: there is an optionanl field containing the VPN username after the first IP address in our ASA logs that is not accounted for in the parsing rules of signature IDs 278-305011 ("Built dynamic/static TCP/UDP/ICMP translation") and 278-305012 ("Teardown dynamic/static TCP/UDP/ICMP translation").
(I know I could get rid of those by choosing "Do nothing" instead of "Log unknown events" in the data source configuration, but I prefer to see unrecognized events instead of ignoring them - if "Do nothing" hed been selected in this case, I would never have known that certain events were ignored).
Glad you got to the bottom of it, Marc. I hope you'll submit an enhancement request to have the rules updated to take into account the additional field. Parser enhancement requests can be submitted via the following portal:
Here's a doc that provides guidance on data that is helpful in these situations.