Hello,
I am having troubles with the x-ratelimit-reset header. Based on this post (https://www.themoviedb.org/talk/5317af69c3a3685c4a0003b1), I understood that this header corresponds to the epoch timestamps when the counter is reset. The problem I have is when I compare it with a "current" timestamp after a request, I get a number of seconds greater than 10 (15-16s most of the time). So I thought you had changed the timeframe, but when I looked at the date header sent back by your server, I found it was actually in the "future" compared with a timestamp on my machine.
I checked my machine against this source (http://www.epochconverter.com/) and I'm pretty much on time. However, your server seems to be rushing by 8-10 seconds. Consequently, there's no way for me to know when I will really be able to make new requests. It might be a good idea to send the number of seconds (or milliseconds) remaining before we can make new requests; so that you don't care at all if the server's on time.
What do you think ?
Other than that, awesome work, this API is great !
لم تجد الفلم أو المسلسل ؟ سجل دخولك و انشئها
هل تريد تقييم او اضافة هذا العنصر للقائمة؟
لست عضو؟
رد بواسطة Travis Bell
بتاريخ سبتمبر 16, 2015 في 4:18 مساءا
Hi WaldoJeffers,
You should be able to keep track of the reset by storing the time of the first request you make (or once the counter has been reset). With that initial time you can calculate the offset in relation to the time we return by the
Date
header. Since we reset the counter every 10 seconds (or simply at the time specified byX-RateLimit-Reset
you can accurately gauge when the next reset will be local to whatever time your client is returning.For what it's worth, I just tested the time our servers are reporting and they are within 1 second (less than) of what epochconverter.com is reporting.