4 ms·

100 days to display a server generated clock rather than a client side one.

icebraining 13y ago
But they don't really have to display a server generated clock, just pre-seed the client clock with the current server time in order to account for the offset. If they want to be really sure, they can re-set the offset regularly using AJAX. There's no need to reimplement the whole clock.
- VLM 13y ago
  "There's no need to reimplement the whole clock." Its a pity it "has to be" a symbolic fake looking virtual clock. A webcam snapshot updated every minute or a live video feed of the actual real world big ben clock would look cooler and be infinitely more impressive and "British" (British being the first word of BBC) Yes its not HTML5/CSS3/JS/AJAX but the tech infrastructure to cache semi-live real world pix like this would also be technologically cool, so don't worry about it. Now... go reimplement Big Ben (just kidding) (Edited to add, also you're also outsourcing your problem with this strategy... Time on Big Ben is wrong, who cares its not your problem, tell the Queen or whoever is in charge of Big Ben, its no longer a web developer problem)
- lucian1900 13y ago
  You can't "just" pre-seed with the current server time, since there is latency between the server sending it and the client receiving it.
  - shawabawa3 13y ago
    I don't think the clock has to be accurate to the ms. The latency between client and server will almost always be < 1 second. They can probably get away with time being accurate to ~1minute
radio4fan 13y ago
Sure. 99.5 days of management busy-work, and 4 hours coding, testing and deploying.
- andyhmltn 13y ago
  I would even say 4 hours is a bit too long.
berkut 13y ago
How does that work with timezones and summertime? They also then can't use caching - that's going to impact them a bit I think...
- webjunkie 13y ago
  It's only for UK time. And nowhere it says it has to be included in the HTML itself. Ever heard of JavaScript?

But they don't really have to display a server generated clock, just pre-seed the client clock with the current server time in order to account for the offset. If they want to be really sure, they can re-set the offset regularly using AJAX. There's no need to reimplement the whole clock.

VLM 13y ago
"There's no need to reimplement the whole clock." Its a pity it "has to be" a symbolic fake looking virtual clock. A webcam snapshot updated every minute or a live video feed of the actual real world big ben clock would look cooler and be infinitely more impressive and "British" (British being the first word of BBC) Yes its not HTML5/CSS3/JS/AJAX but the tech infrastructure to cache semi-live real world pix like this would also be technologically cool, so don't worry about it. Now... go reimplement Big Ben (just kidding) (Edited to add, also you're also outsourcing your problem with this strategy... Time on Big Ben is wrong, who cares its not your problem, tell the Queen or whoever is in charge of Big Ben, its no longer a web developer problem)
lucian1900 13y ago
You can't "just" pre-seed with the current server time, since there is latency between the server sending it and the client receiving it.
- shawabawa3 13y ago
  I don't think the clock has to be accurate to the ms. The latency between client and server will almost always be < 1 second. They can probably get away with time being accurate to ~1minute

radio4fan 13y ago

Sure. 99.5 days of management busy-work, and 4 hours coding, testing and deploying.

andyhmltn 13y ago
I would even say 4 hours is a bit too long.

berkut 13y ago

How does that work with timezones and summertime? They also then can't use caching - that's going to impact them a bit I think...

webjunkie 13y ago
It's only for UK time. And nowhere it says it has to be included in the HTML itself. Ever heard of JavaScript?