There's a plugin which corrects this, called Smart Update Pinger. I don't have a link, but you should be able to google it.

BTW, your future posts are completely unavailable to anyone except a logged in admin (i.e. you!) but it is a good idea to restrict when pings are sent, because if too many are sent out, you can get banned from the services.

Thanks for the responce. I probably should have mentioned that I already know about that plugin, and have spoken with Skippy (the developer) about it. He himself said that it's pretty unreliable and may or may not do what we want it to do when it's supposed to. That's why I was looking for another solution.

The main problem is that as soon as WP pings the update services, they then list that post on their site which then gets crawled by SE spiders. The spiders then follow the link they find back to my site and put the page content in their index of search results.

Now, that's usually a very good thing, ( :o) ) except when I don't want the SE to know about the content.

See, it's not so much about people coming to see what I've posted, that's a secondary issue. The main issue is the search engines themselves. I want them to see my blogs being updated on a certain schedule, in my case daily.

This helps "train" them to keep coming back and crawling my site and (some SEO's believe) can make a slight difference in the rank my content is assigned in the search results.

So that's why I'm looking for a solution to this, I don't want the SE's to find and index my content before I'm ready and pinging the notification services at the time of the post as opposed to the time it's set to publish kinda "blows the cover".

That's odd -- there had been a long discussion about this topic on the mailing list, and I though a fix had been put in.... which was that since there's this 'wp-cron' thing running processes on schedules, and I >thought< it was also responsible for turning loose the future posts, it would load up the pings when it flipped a future post active.

... a quick look at trac shows that fixes were put into the 2.1 branch, so should be in that release. If you got bleeding-edge code from SVN, it'd have the fixes in place.