*Question:* I'm tweeting throught twitter for iPhone and geotagging each tweet.
When I try this search API query http://search.twitter.com/search.json?geocode=-33.4135,-70.5999,10mi&q=danielatik <http://search.twitter.com/search.json?geocode=-33.4135,-70.5999,10mi&q=danielatik>I cannot see GEO lat, long information. Any idea? Daniel Atik 2010/6/22 Peter Cross <zootl...@gmail.com> > Thanks for the explanation. It's easy enough to parse, it just seemed > so bizarre (and I was having a bad oAuth day!). -ZPC > > On Jun 21, 4:37 pm, themattharris <thematthar...@twitter.com> wrote: > > The time format is a little weird and as far as I know, doesn't match > > any RFC. Instead it matches the ruby default and is represented in > > tokens by: > > %a %b %d %H:%M:%S %Z %Y > > > > The format has been like this since the API was first released which > > means, for backwards compatibility with other applications, we can't > > easily change it with this version of the API. > > > > I hope that explains the why it is still in the format it is. > > Hopefully you can use the token string above to parse the date using > > the time parsing functions of your chosen language. > > > > Matt > > > > On Jun 21, 12:40 pm, Peter Cross <zootl...@gmail.com> wrote: > > > > > > > > > This date is from a call tohttp:// > api.twitter.com/1/statuses/user_timeline.xml: > > > > > <created_at>Mon Jun 21 19:06:21 +0000 2010</created_at> > > > > > <begin rant> > > > > > I've never seen the year come after the time... in any standard date > > > format. It's as if someone thought "Hmmm... how can we make this date > > > format more difficult to work with?". Why, why why? Now I have to > > > write a special handler for this one exception. It's sloppy. > > > > > </end rant> > > > > > This isn't an XML standard date format either. > > > > > -ZPC
