[twitter-dev] Re: created_at format
We do intend to move to unified format. This inconsistency is the result of the Search system being developed independently of Twitter before it was acquired. On Tue, Aug 11, 2009 at 13:33, Jonas wrote: > > I am using search.json and track.json and I noticed that the date > format for created_at is different. > > search.json: Tue, 11 Aug 2009 20:23:36 + > track.json: Tue Aug 11 20:23:36 + 2009 > > Is there a reason why Twitter uses different formats for the same > information? > > Is there any interest in using just one format? I would prefer the > format outputted by search.json because it is easily parsed by the > DateTime object in .NET. > > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: created_at format change
Done.
http://code.google.com/p/twitter-api/issues/detail?id=740&colspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component
Cheers,
--
Yusuke Yamamoto
yus...@mac.com
this email is: [x] bloggable/twittable [ ] ask first [ ] private
follow me on : http://twitter.com/yusukeyamamoto
subscribe me at : http://yusuke.homeip.net/blog/
On 6月24日, 午後12:56, Doug Williams wrote:
> I'm seeing that, too. Can you open a ticket?
>
> http://code.google.com/p/twitter-api/issues/list
>
> Thanks,
> Doug
>
> --
> Do you follow me?http://twitter.com/dougw
>
> 2009/6/23 H12山本 裕介
>
>
>
>
>
> > Hi,
>
> > After the change, the API started to return status code:403 when there
> > is no matching tweets.
> > It used to be returning status code 404.
> > Will this be a permanent behavior?
> > ---
> > [Wed Jun 24 12:50:31 JST 2009]GET
> >http://search.twitter.com/search.json?q=from%3Atwit4j+doesnothit
> > [Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-URL:
> >http://yusuke.homeip.net/twitter4j/en/twitter4j-undefined.xml
> > [Wed Jun 24 12:50:31 JST 2009]Accept-Encoding: gzip
> > [Wed Jun 24 12:50:31 JST 2009]User-Agent: twitter4j
> >http://yusuke.homeip.net/twitter4j/
> > /undefined
> > [Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-Version: undefined
> > [Wed Jun 24 12:50:31 JST 2009]Response:
> > [Wed Jun 24 12:50:31 JST 2009]HTTP/1.1 403 Forbidden
> > [Wed Jun 24 12:50:31 JST 2009]Age: 0
> > [Wed Jun 24 12:50:31 JST 2009]X-Served-From: searchdb014
> > [Wed Jun 24 12:50:31 JST 2009]Content-Length: 53
> > [Wed Jun 24 12:50:31 JST 2009]Expires: Wed, 24 Jun 2009 03:55:32 GMT
> > [Wed Jun 24 12:50:31 JST 2009]X-Served-By: searchweb014.twitter.com
> > [Wed Jun 24 12:50:31 JST 2009]Connection: close
> > [Wed Jun 24 12:50:31 JST 2009]Server: hi
> > [Wed Jun 24 12:50:31 JST 2009]X-Cache: MISS
> > [Wed Jun 24 12:50:31 JST 2009]Cache-Control: max-age=60, must-
> > revalidate, max-age=300
> > [Wed Jun 24 12:50:31 JST 2009]Status: 403 Forbidden
> > [Wed Jun 24 12:50:31 JST 2009]X-Varnish: 120647426
> > [Wed Jun 24 12:50:31 JST 2009]Date: Wed, 24 Jun 2009 03:50:32 GMT
> > [Wed Jun 24 12:50:31 JST 2009]Vary: Accept-Encoding
> > [Wed Jun 24 12:50:31 JST 2009]Content-Encoding: gzip
> > [Wed Jun 24 12:50:31 JST 2009]Via: 1.1 varnish
> > [Wed Jun 24 12:50:31 JST 2009]X-Cache-Svr: searchweb014.twitter.com
> > [Wed Jun 24 12:50:31 JST 2009]Content-Type: application/json;
> > charset=utf-8
> > [Wed Jun 24 12:50:31 JST 2009]{"error":"Exceptions::NoResults"}
> > ---
>
> > Cheers,
> > --
> > Yusuke Yamamoto
> > yus...@mac.com
>
> > this email is: [x] bloggable/twittable [ ] ask first [ ] private
> > follow me on :http://twitter.com/yusukeyamamoto
> > subscribe me at :http://yusuke.homeip.net/blog/
>
> > On 6月24日, 午後12:44, Chad Etzel wrote:
> > > Yep, looking good.
>
> > > On Tue, Jun 23, 2009 at 11:30 PM, Brooks Bennett
> > wrote:
>
> > > > Looks fixed now. Thanks!
>
> > > > On Jun 23, 9:24 pm, Matt Sanford wrote:
> > > >> This was not intentional and I'm trying to get to the bottom of it
> > now.
>
> > > >> -- Matt
>
> > > >> On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote:
>
> > > >> > Yeah, all of my timestamps are now busted and I'm just finding
> > out...
> > > >> > It looks like this was just a change in the Search API format, and
> > not
> > > >> > the REST API format? Is that correct?
>
> > > >> > Going bonkers,
> > > >> > -Chad
>
> > > >> > On Tue, Jun 23, 2009 at 9:02 PM, Christopher
> > > >> > Finke wrote:
>
> > > >> >> Around 7:45pm Central time, I noticed that the format of the
> > > >> >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +"
> > > >> >> to
> > > >> >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so,
> > was
> > > >> >> it communicated anywhere? We had to rush out a fix to our app in
> > > >> >> order to change the format string we were using to parse the date.
>
> > > >> >> (The true issue, of course, is that Python needs a strtotime() like
> > > >> >> PHP. :-)
>
> > > >> >> Chris
[twitter-dev] Re: created_at format change
I'm seeing that, too. Can you open a ticket?
http://code.google.com/p/twitter-api/issues/list
Thanks,
Doug
--
Do you follow me? http://twitter.com/dougw
2009/6/23 H12山本 裕介
>
> Hi,
>
> After the change, the API started to return status code:403 when there
> is no matching tweets.
> It used to be returning status code 404.
> Will this be a permanent behavior?
> ---
> [Wed Jun 24 12:50:31 JST 2009]GET
> http://search.twitter.com/search.json?q=from%3Atwit4j+doesnothit
> [Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-URL:
> http://yusuke.homeip.net/twitter4j/en/twitter4j-undefined.xml
> [Wed Jun 24 12:50:31 JST 2009]Accept-Encoding: gzip
> [Wed Jun 24 12:50:31 JST 2009]User-Agent: twitter4j
> http://yusuke.homeip.net/twitter4j/
> /undefined
> [Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-Version: undefined
> [Wed Jun 24 12:50:31 JST 2009]Response:
> [Wed Jun 24 12:50:31 JST 2009]HTTP/1.1 403 Forbidden
> [Wed Jun 24 12:50:31 JST 2009]Age: 0
> [Wed Jun 24 12:50:31 JST 2009]X-Served-From: searchdb014
> [Wed Jun 24 12:50:31 JST 2009]Content-Length: 53
> [Wed Jun 24 12:50:31 JST 2009]Expires: Wed, 24 Jun 2009 03:55:32 GMT
> [Wed Jun 24 12:50:31 JST 2009]X-Served-By: searchweb014.twitter.com
> [Wed Jun 24 12:50:31 JST 2009]Connection: close
> [Wed Jun 24 12:50:31 JST 2009]Server: hi
> [Wed Jun 24 12:50:31 JST 2009]X-Cache: MISS
> [Wed Jun 24 12:50:31 JST 2009]Cache-Control: max-age=60, must-
> revalidate, max-age=300
> [Wed Jun 24 12:50:31 JST 2009]Status: 403 Forbidden
> [Wed Jun 24 12:50:31 JST 2009]X-Varnish: 120647426
> [Wed Jun 24 12:50:31 JST 2009]Date: Wed, 24 Jun 2009 03:50:32 GMT
> [Wed Jun 24 12:50:31 JST 2009]Vary: Accept-Encoding
> [Wed Jun 24 12:50:31 JST 2009]Content-Encoding: gzip
> [Wed Jun 24 12:50:31 JST 2009]Via: 1.1 varnish
> [Wed Jun 24 12:50:31 JST 2009]X-Cache-Svr: searchweb014.twitter.com
> [Wed Jun 24 12:50:31 JST 2009]Content-Type: application/json;
> charset=utf-8
> [Wed Jun 24 12:50:31 JST 2009]{"error":"Exceptions::NoResults"}
> ---
>
> Cheers,
> --
> Yusuke Yamamoto
> yus...@mac.com
>
> this email is: [x] bloggable/twittable [ ] ask first [ ] private
> follow me on : http://twitter.com/yusukeyamamoto
> subscribe me at : http://yusuke.homeip.net/blog/
>
>
> On 6月24日, 午後12:44, Chad Etzel wrote:
> > Yep, looking good.
> >
> >
> >
> > On Tue, Jun 23, 2009 at 11:30 PM, Brooks Bennett
> wrote:
> >
> > > Looks fixed now. Thanks!
> >
> > > On Jun 23, 9:24 pm, Matt Sanford wrote:
> > >> This was not intentional and I'm trying to get to the bottom of it
> now.
> >
> > >> -- Matt
> >
> > >> On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote:
> >
> > >> > Yeah, all of my timestamps are now busted and I'm just finding
> out...
> > >> > It looks like this was just a change in the Search API format, and
> not
> > >> > the REST API format? Is that correct?
> >
> > >> > Going bonkers,
> > >> > -Chad
> >
> > >> > On Tue, Jun 23, 2009 at 9:02 PM, Christopher
> > >> > Finke wrote:
> >
> > >> >> Around 7:45pm Central time, I noticed that the format of the
> > >> >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +"
> > >> >> to
> > >> >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so,
> was
> > >> >> it communicated anywhere? We had to rush out a fix to our app in
> > >> >> order to change the format string we were using to parse the date.
> >
> > >> >> (The true issue, of course, is that Python needs a strtotime() like
> > >> >> PHP. :-)
> >
> > >> >> Chris
>
[twitter-dev] Re: created_at format change
Hi,
After the change, the API started to return status code:403 when there
is no matching tweets.
It used to be returning status code 404.
Will this be a permanent behavior?
---
[Wed Jun 24 12:50:31 JST 2009]GET
http://search.twitter.com/search.json?q=from%3Atwit4j+doesnothit
[Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-URL:
http://yusuke.homeip.net/twitter4j/en/twitter4j-undefined.xml
[Wed Jun 24 12:50:31 JST 2009]Accept-Encoding: gzip
[Wed Jun 24 12:50:31 JST 2009]User-Agent: twitter4j
http://yusuke.homeip.net/twitter4j/
/undefined
[Wed Jun 24 12:50:31 JST 2009]X-Twitter-Client-Version: undefined
[Wed Jun 24 12:50:31 JST 2009]Response:
[Wed Jun 24 12:50:31 JST 2009]HTTP/1.1 403 Forbidden
[Wed Jun 24 12:50:31 JST 2009]Age: 0
[Wed Jun 24 12:50:31 JST 2009]X-Served-From: searchdb014
[Wed Jun 24 12:50:31 JST 2009]Content-Length: 53
[Wed Jun 24 12:50:31 JST 2009]Expires: Wed, 24 Jun 2009 03:55:32 GMT
[Wed Jun 24 12:50:31 JST 2009]X-Served-By: searchweb014.twitter.com
[Wed Jun 24 12:50:31 JST 2009]Connection: close
[Wed Jun 24 12:50:31 JST 2009]Server: hi
[Wed Jun 24 12:50:31 JST 2009]X-Cache: MISS
[Wed Jun 24 12:50:31 JST 2009]Cache-Control: max-age=60, must-
revalidate, max-age=300
[Wed Jun 24 12:50:31 JST 2009]Status: 403 Forbidden
[Wed Jun 24 12:50:31 JST 2009]X-Varnish: 120647426
[Wed Jun 24 12:50:31 JST 2009]Date: Wed, 24 Jun 2009 03:50:32 GMT
[Wed Jun 24 12:50:31 JST 2009]Vary: Accept-Encoding
[Wed Jun 24 12:50:31 JST 2009]Content-Encoding: gzip
[Wed Jun 24 12:50:31 JST 2009]Via: 1.1 varnish
[Wed Jun 24 12:50:31 JST 2009]X-Cache-Svr: searchweb014.twitter.com
[Wed Jun 24 12:50:31 JST 2009]Content-Type: application/json;
charset=utf-8
[Wed Jun 24 12:50:31 JST 2009]{"error":"Exceptions::NoResults"}
---
Cheers,
--
Yusuke Yamamoto
yus...@mac.com
this email is: [x] bloggable/twittable [ ] ask first [ ] private
follow me on : http://twitter.com/yusukeyamamoto
subscribe me at : http://yusuke.homeip.net/blog/
On 6月24日, 午後12:44, Chad Etzel wrote:
> Yep, looking good.
>
>
>
> On Tue, Jun 23, 2009 at 11:30 PM, Brooks Bennett wrote:
>
> > Looks fixed now. Thanks!
>
> > On Jun 23, 9:24 pm, Matt Sanford wrote:
> >> This was not intentional and I'm trying to get to the bottom of it now.
>
> >> -- Matt
>
> >> On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote:
>
> >> > Yeah, all of my timestamps are now busted and I'm just finding out...
> >> > It looks like this was just a change in the Search API format, and not
> >> > the REST API format? Is that correct?
>
> >> > Going bonkers,
> >> > -Chad
>
> >> > On Tue, Jun 23, 2009 at 9:02 PM, Christopher
> >> > Finke wrote:
>
> >> >> Around 7:45pm Central time, I noticed that the format of the
> >> >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +"
> >> >> to
> >> >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was
> >> >> it communicated anywhere? We had to rush out a fix to our app in
> >> >> order to change the format string we were using to parse the date.
>
> >> >> (The true issue, of course, is that Python needs a strtotime() like
> >> >> PHP. :-)
>
> >> >> Chris
[twitter-dev] Re: created_at format change
Yep, looking good. On Tue, Jun 23, 2009 at 11:30 PM, Brooks Bennett wrote: > > Looks fixed now. Thanks! > > On Jun 23, 9:24 pm, Matt Sanford wrote: >> This was not intentional and I'm trying to get to the bottom of it now. >> >> — Matt >> >> On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote: >> >> >> >> >> >> > Yeah, all of my timestamps are now busted and I'm just finding out... >> > It looks like this was just a change in the Search API format, and not >> > the REST API format? Is that correct? >> >> > Going bonkers, >> > -Chad >> >> > On Tue, Jun 23, 2009 at 9:02 PM, Christopher >> > Finke wrote: >> >> >> Around 7:45pm Central time, I noticed that the format of the >> >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" >> >> to >> >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was >> >> it communicated anywhere? We had to rush out a fix to our app in >> >> order to change the format string we were using to parse the date. >> >> >> (The true issue, of course, is that Python needs a strtotime() like >> >> PHP. :-) >> >> >> Chris >
[twitter-dev] Re: created_at format change
Looks fixed now. Thanks! On Jun 23, 9:24 pm, Matt Sanford wrote: > This was not intentional and I'm trying to get to the bottom of it now. > > — Matt > > On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote: > > > > > > > Yeah, all of my timestamps are now busted and I'm just finding out... > > It looks like this was just a change in the Search API format, and not > > the REST API format? Is that correct? > > > Going bonkers, > > -Chad > > > On Tue, Jun 23, 2009 at 9:02 PM, Christopher > > Finke wrote: > > >> Around 7:45pm Central time, I noticed that the format of the > >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" > >> to > >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was > >> it communicated anywhere? We had to rush out a fix to our app in > >> order to change the format string we were using to parse the date. > > >> (The true issue, of course, is that Python needs a strtotime() like > >> PHP. :-) > > >> Chris
[twitter-dev] Re: created_at format change
Thanks for looking into this. On Jun 23, 9:24 pm, Matt Sanford wrote: > This was not intentional and I'm trying to get to the bottom of it now. > > — Matt > > On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote: > > > > > > > Yeah, all of my timestamps are now busted and I'm just finding out... > > It looks like this was just a change in the Search API format, and not > > the REST API format? Is that correct? > > > Going bonkers, > > -Chad > > > On Tue, Jun 23, 2009 at 9:02 PM, Christopher > > Finke wrote: > > >> Around 7:45pm Central time, I noticed that the format of the > >> created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" > >> to > >> "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was > >> it communicated anywhere? We had to rush out a fix to our app in > >> order to change the format string we were using to parse the date. > > >> (The true issue, of course, is that Python needs a strtotime() like > >> PHP. :-) > > >> Chris
[twitter-dev] Re: created_at format change
It seems all the server don't return the same date format ... probably because of the cached results... What is the recommended action ? is this new format going to be the good one from now on? Should we fix it ? Stephane On Jun 23, 6:02 pm, Christopher Finke wrote: > Around 7:45pm Central time, I noticed that the format of the > created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" to > "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was > it communicated anywhere? We had to rush out a fix to our app in > order to change the format string we were using to parse the date. > > (The true issue, of course, is that Python needs a strtotime() like > PHP. :-) > > Chris
[twitter-dev] Re: created_at format change
yes, I found this as well. -Jeff On Jun 23, 6:02 pm, Christopher Finke wrote: > Around 7:45pm Central time, I noticed that the format of the > created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" to > "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was > it communicated anywhere? We had to rush out a fix to our app in > order to change the format string we were using to parse the date. > > (The true issue, of course, is that Python needs a strtotime() like > PHP. :-) > > Chris
[twitter-dev] Re: created_at format change
Update: We just deployed a fix for this bug. the format should be back to normal. Thanks; — Matt Sanford / @mzsanford On Jun 23, 2009, at 7:24 PM, Matt Sanford wrote: This was not intentional and I'm trying to get to the bottom of it now. Matt On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote: Yeah, all of my timestamps are now busted and I'm just finding out... It looks like this was just a change in the Search API format, and not the REST API format? Is that correct? Going bonkers, -Chad On Tue, Jun 23, 2009 at 9:02 PM, Christopher Finke wrote: Around 7:45pm Central time, I noticed that the format of the created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" to "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was it communicated anywhere? We had to rush out a fix to our app in order to change the format string we were using to parse the date. (The true issue, of course, is that Python needs a strtotime() like PHP. :-) Chris
[twitter-dev] Re: created_at format change
This was not intentional and I'm trying to get to the bottom of it now. — Matt On Jun 23, 2009, at 7:05 PM, Chad Etzel wrote: Yeah, all of my timestamps are now busted and I'm just finding out... It looks like this was just a change in the Search API format, and not the REST API format? Is that correct? Going bonkers, -Chad On Tue, Jun 23, 2009 at 9:02 PM, Christopher Finke wrote: Around 7:45pm Central time, I noticed that the format of the created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" to "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was it communicated anywhere? We had to rush out a fix to our app in order to change the format string we were using to parse the date. (The true issue, of course, is that Python needs a strtotime() like PHP. :-) Chris
[twitter-dev] Re: created_at format change
Yeah, all of my timestamps are now busted and I'm just finding out... It looks like this was just a change in the Search API format, and not the REST API format? Is that correct? Going bonkers, -Chad On Tue, Jun 23, 2009 at 9:02 PM, Christopher Finke wrote: > > Around 7:45pm Central time, I noticed that the format of the > created_at timestamp changed from "Fri, 15 May 2009 14:41:50 +" to > "2009-05-15 14:41:50 UTC". Was this change intentional? If so, was > it communicated anywhere? We had to rush out a fix to our app in > order to change the format string we were using to parse the date. > > (The true issue, of course, is that Python needs a strtotime() like > PHP. :-) > > Chris >
