i've got a working solution as far as pulling in tweets doing pretty much as I said, except that.it will fail when there is a burst of tweets. For some very active search term, say something that exceeds the 1500 search limit (15 pages x100tweets/pg) per day... Tweets will be missed. For my application, i the odds are that missing a small quantity of tweets isn't earth shattering, but there's a *chance* it could be.. I think of this as a twitter shortcoming... Wondering if it's worth filing a low-priority bug for it?
On Fri, May 22, 2009 at 1:24 PM, Doug Williams <d...@twitter.com> wrote: > As the docs [1] state the correct format is since:YYYY-MM-DD which give you > resolution down to a day. Any further processing must be done on the client > side. Given the constraints, utilizing a combination of since: and since_id > sounds like a great solution. > 1. http://search.twitter.com/operators > > Thanks, > Doug > -- > > Doug Williams > Twitter Platform Support > http://twitter.com/dougw > > > > > > On Fri, May 22, 2009 at 8:05 AM, Jeffrey Greenberg < > jeffreygreenb...@gmail.com> wrote: > >> What is the resolution of the 'since' operator? It appears to be by the >> day, but I'd sure like it to be by the minute or second. >> Can't seem to find this in the docs. >> >> The use case is that I want to minimize pulling searches results that i've >> already got. My solution is to record the time of the last search and the >> last status_id, and ask for subsequent searches from the status_id. If that >> fails because it's out of range, I'll ask by the last search date. Is this >> the way to go? >> >> >> http://www.tweettronics.com >> http://www.jeffrey-greenberg.com >> >> >
