CloudFront, as you likely know, is a globally-distributed system where provisioning is centralized, but the 50+ edge locations operate independently once provisioning is pushed out to them.
The logs are, presumably, collected either locally at each edge, or regionally, and then periodically collected and assembled into consolidated logs and published to your log bucket.
The timestamp embedded in the log file name represents, approximately, the hour during which the contained events occurred. As such, the log for a given hour will often not arrive during an hour, or even in the hour immedately following.
If anything prevents the logs from certain edges from being collected in a timely fashion (as would be expected in a global, distributed platform), they will normally arrive within a few hours, in a back-dated log file that represents the approximate time the logs were originally recorded.
Timing of Log File Delivery
CloudFront delivers access logs for a distribution up to several times an hour. In general, a log file contains information about the requests that CloudFront received during a given time period. CloudFront usually delivers the log file for that time period to your Amazon S3 bucket within an hour of the events that appear in the log. Note, however, that some or all log file entries for a time period can sometimes be delayed by up to 24 hours. When log entries are delayed, CloudFront saves them in a log file for which the file name includes the date and time of the period in which the requests occurred, not the date and time when the file was delivered.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-timing
So, essentially, CloudFront will create at least one log file for each hour that your distribution has any traffic, but a log can arrive at essentially any time... so you can't effectively poll the bucket looking for certain patterns based on the current time, the time of the previous hour, etc.
One way to handle these as expeditiously as possible (without polling the bucket) is S3 event notifications.
In any event, you do need to be prepared to handle any timestamp, whenever it's written, don't assume duplications, and don't disregard a log because it has a timestamp that seems older than expected.