How can we improve

Server should return its idea of "current time" for reliable delta ("last check X seconds ago", etc)

When I added "last check" and "next check" information on my custom status page using the API, I opted to give a handy "time delta", for instance I might say things like (paraphrased) "the last check was 04:42 ago at 00:46:08" and "the next check will be in 00:18 at 00:51:08".

This of course requires having an idea of what the "current time" is.

I initially used simply the (client) time at which I sent the request to the server, but obviously that's fundamentally flawed in many ways, as the client clock and server clock may not be synchronised, and of course there are various processing and communication delays. So basically this was just a guess, and sometimes I would end up with last checks in the "future" or next checks in the "past".

To mitigate this, I simply "clamped" the client time to force it to be between the last check and the next check, and this does help a bit, but at the end of the day, this is still just a guess and sometimes the page will say that the next check is in "0 seconds", and then I wait a bit and refresh the page and it still says that the check is in 0 seconds, which probably means that my guess as what the "current time" is was actually in the "future" compared to the server.

So, it would be great if the server could simply return its idea of what the current time is. I realize this would not be entirely pain-free to implement in a sane way while retaining backwards compatibility.

One idea, using "GET /api/checks" as an example, would be to add a parameter, "request_current_time" (defaulting to false), and in that case the response would be "{current_time: 2018-08-14T04:50:28Z, checks: data}" instead of just "data".

I realize you may be unwilling to implement this, but I thought it was important to point out the flaw in case you make a newer version of the API at some point. (Have you looked into GraphQL? Seems very promising!)

3 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Jean-Philippe Paradis shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
completed  ·  AdminAdrien Rey-Jarthon (CEO / Founder, responded  · 

This is a legit question and fortunately it has already been tackled by HTTP. You can find in the API response headers the “Date” field which contains the local server time. You can use it as a baseline for your time difference comparisons.

It is not by default accessible for CORS requests but I’ve just added the proper expose header so it’s now accessible from javascript too, here is an example:

fetch(“”).then(function(res) { console.log(res.headers.get(“date”)) })

Feel free to use it now :)

But keep in mind that next_check time being in the past will still happen, this is because it’s value is updated after the check, which can take time (between 0 and 30 seconds depending on the server response time and latency) So it can be up to 30 seconds late even on synchronized clock, in this case, you can display something like: “currently running” or something like that if you prefer ;)

ps: thanks for the updates on older tickets


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
An error occurred while saving the comment

Feedback and Knowledge Base