Comment: Re:User's time, not BBC time (Score 1) 487
1) Clock drift in excess of a minute per day is not unheard-of.
I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.
2) If the AJAX request fails, what do you do?
For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.
3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.
You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.
4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?
I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.
I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.
5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.
What daylight savings time? There's a reason why I'm using milliseconds since Epoch.
If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.
