Indeed, it seems like the status hasn't changed.
Best regards, Horst
<?xml version="1.0" encoding="UTF-8"?>
...and in JSON:
"reset_time":"Fri Jun 27 13:36:28 -0700 2008"
Sounds good to me, all relevant information included.
Sent from my iPhone
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. :)
Ah, ok. I've seen this with my own account in Twitterific as well.
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.
I really think it needs to be "the number of seconds until the reset"
- that would be far more reliable for client use.