Usually at least in my experience, these are attributable to wrong time zone setting on a given event source.
Click on your physical display, home, event summary, event drilldown, > events, set a custom time range to be the future, review those events. When clicking on each event, in the details tab, you'll see what event source the event came from. Repeat the fixup of the wrong time zones until they go away.
It's a seriously clunky a**ed process that probably warrants a product enhancement request to refine it and make it easier, but I'm saving the arrows in my quiver for even bigger issues with this product. :-)
There are several possibilities for this issue.
The first is what Regis suggested, a Time Zone issue.
The second could be that certain logs do not contain a time stamp, and the system is using GMT instead of the Data Sources Time Zone / Database insertion time as the time stamp (this is one of my problems with 9.3.2).
The third could be a data source with Auto-Learned rules not parsing data with the fields you would expect, for example, we have Linux Audit Log messages being parsed by the Unix / Linux (ASP) parser that are all "Auto-Learned" rules. There is a human readable data and time at the beginning of the messages, however later in the message there is an EPOCH time. The EPOCH time is in GMT and that is what is being parsed, not taking in to account that the Data Source is setup for CST, and not taking in to account the human readable time at the beginning of the packet.
I have had a PER in for a while now to resolve this issue.
The solution provided by Regis yeilds no events when I set a custom/future date.
I would be interested in hearing more about you Options 2 and 3. How can I identify the "problem" logs?
For the "Auto-Learned" parser rules that I am having issues with, they are Linux Audit Messages, example shown below:
<182>Jul 17 05:01:10 SERVER_NAME audit type=PATH msg=audit(1405591270.186:15131): item=0 name="stat-audit-log" inode=13 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_runtime_t:s0
EPOCH Time for "1405591270" = GMT: Thu, 17 Jul 2014 10:01:10 UTC - this is the time the ESM is using to parse and not the human readable time at the beginning of the packet, or take in to account that my Data Source is set for CST and subtract the 5 hours from the GMT/UTC time.
I used the following website for EPOCH Time conversion - http://www.epochconverter.com/
Also - Unknown Events may ignore any timestamps in their packets, and would parse as GMT, this is supposedly fixed in 9.3.2 HF10, as you are running 9.4.0 you may need to report this as an issue to be resolved.
I just read that one of the known issues with 9.4 is "Custom Views" do not load, hence my problem with not seeing any events when I choose that option. This is supposed to be addressed in HF1 for 9.4.
Ouch, we have hundreds of custom views, that is practically all we use, as well as over 100 custom displays.