A Timestamp difference of 19 seconds is noticiable, but it may have no impact on authorizations. It does not affect your current problem.
Checking the log, a specific case:
"Melker Garay. Gud finns bortom Gud" was received at 2015-08-12 07:58:19 (GMT) with publishing up date of 2015-08-12 06:00:00 (GMT). Thus, it was delivered inmediately at the first processing opportunity.
Just to check, are you saving the article at the first time with the final publishing date? or, you define the publishing date at the end of edition. (By default, AutoTweet processes the article creation only).
First we create the article with Form2Content CCK (which produces the article) from front end - let say at day 1 - and at the same time we set the publishing date for day 3 (at midnight), but also keeps the article "unpublished". On day 2, I proof reed the article within F2C component in backend, and set the publishing time to, for example, 08:00 in the morning, publish and save the article. It is when I save the article as "published" AutoTweet seems to "discover" it and put it in the queue (in Composer view in your component) for posting to Facebook. It isn't in the queue upon creation, before day 2. I have set the plugins to process modifications.
Right now, for example, we have a dozen new, unpublished articles for next week. But they aren't in the queue. During the weekend I will proof read and set the correct time for publishing and publish the article. It then goes into the queue on the correct date and time. And it post to facebook without a problem.
But if someone after publishing the article tries to share it on facebook, we got the 404 error in facebook (but the link will work, if clicked on). If I go to the facebook debugger, I can notice that the scrape date either is in 1 january, 1970, or the creation date of the article. And therefore produces the 404 error. If I ask the debugger to fetch the url again, sharing is possible.
If we instead tries to share the link with the suffix described earlier (fb_ref=default), and which the article is shared as by AutoTweet, it show the image and intro text as normal. Sometimes, though, it seems to be some issues here also - because the introtext shared by this "manual" method is sometimes NOT the article's intro text, but the last autoposted article's introtext (posted by AutoTweet), but the image is correct - strange, eh?
Therefore I was wondering if there was a way for AutoTweet to share the link without this suffix to force Facebook to scrape the url again, maybe solving all issues at once...
Sorry for the long post, but maybe you can see a pattern here that causes the issue..?