--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
Indeed, it seems like the status hasn't changed.
--
Ed Finkler
{
"remaining_hits":19,
"max_hits":20
}
Best regards, Horst
<?xml version="1.0" encoding="UTF-8"?>
<hash>
<remaining-hits type="integer">19</remaining-hits>
<hourly-limit type="integer">20</hourly-limit>
<reset-time-in-seconds type="integer">1214598988</reset-time-in-seconds>
<reset-time type="datetime">2008-06-27T13:36:28-07:00</reset-time>
</hash>
...and in JSON:
{
"remaining_hits":19,
"hourly_limit":20,
"reset_time_in_seconds":1214598988,
"reset_time":"Fri Jun 27 13:36:28 -0700 2008"
}
--
Alex Payne
http://twitter.com/al3x
Sounds good to me, all relevant information included.
Sent from my iPhone
-Stut
--
Alex Payne
http://twitter.com/al3x
Alex said they would try to get it in this coming week, so what you
read earlier in this thread was just a spec. So no, it's not supposed
to be working as specified just yet.
Secondly, I think that it was supposed to be milliseconds, even though
it was referred to as seconds. Otherwise, none of us will be
programming the Twitter API by the time it resets. :)
-damon
Ah, ok. I've seen this with my own account in Twitterific as well.
Thanks,
-damon
I've rarely seen time/date libraries that can easily covert from
milliseconds without a bunch of multiplication or nested calls, but
most every language has a one-shot call from a epoch time integer to a
native time/date format.
Are we on the same page, or are you asking for something different?
I'm not sure why the number of seconds until the rate limit is reset
is more inherently useful than a timestamp. It seems like a client
could easily calculate the difference between the current time and the
reset-time timestamp if necessary.
--
Alex Payne
http://twitter.com/al3x
I really think it needs to be "the number of seconds until the reset"
- that would be far more reliable for client use.
-Stut
Evan
--
Evan Weaver