3 ms·

Ignoring the issue whether a clock on a website is even remotely useful, this: > The corporation also added that it would take around '100 staffing days to mak

Ignoring the issue whether a clock on a website is even remotely useful, this: > The corporation also added that it would take around '100 staffing days to make the changes involved in switching to an independent clock'. strikes me as at least slightly odd. Shouldn’t such a change be implementable by sending a ‘starting time’ with the initial request and then count using JS? I’m one of these why-does-your-field-even-have-its-own-journal-guys, but this doesn’t look particularly difficult to me.

lttlrck 13y ago
Actually all they need do is add a disclaimer...
deleted 13y ago
[deleted]
thomasahle 13y ago
It still wouldn't work if the users clock, say, ticked at double speed or not at all.
- martin-adams 13y ago
  Still wouldn't work if their monitor was off. Is such a thing a real concern?
IanCal 13y ago
That depends on the accuracy required. 1) How much drift is ok? Do you need to keep sending updates? 2) These pages should be heavily cached, which means the time you get will be out by potentially several minutes (or you've got to have a very short term cache for just the clock). 3) Load time. If the request takes 1s but you need to be accurate to the second then do you need to try and measure the initial request time and determine the likely delays? 4) Managing all the timezones. If the clock must show the local time then you can't just send server time back, we've got to send different things for different regions. How accurate does that have to be? Will Geo-IP be enough? Changes of the size 2-4 will require new code, load testing, QA, code reviews. Plus you've got to take people from projects / push back timescales, which need to be weighed and approved (what deadlines are coming up? What change freezes?).
lucian1900 13y ago
The server time would drift by the latency from server to browser to start with.
- antihero 13y ago
  "reflect as accurately as possible, bearing in mind the technological constraints of delivering data across the internet"

lttlrck 13y ago

Actually all they need do is add a disclaimer...

deleted 13y ago

[deleted]

thomasahle 13y ago

It still wouldn't work if the users clock, say, ticked at double speed or not at all.

martin-adams 13y ago
Still wouldn't work if their monitor was off. Is such a thing a real concern?

IanCal 13y ago

That depends on the accuracy required. 1) How much drift is ok? Do you need to keep sending updates? 2) These pages should be heavily cached, which means the time you get will be out by potentially several minutes (or you've got to have a very short term cache for just the clock). 3) Load time. If the request takes 1s but you need to be accurate to the second then do you need to try and measure the initial request time and determine the likely delays? 4) Managing all the timezones. If the clock must show the local time then you can't just send server time back, we've got to send different things for different regions. How accurate does that have to be? Will Geo-IP be enough? Changes of the size 2-4 will require new code, load testing, QA, code reviews. Plus you've got to take people from projects / push back timescales, which need to be weighed and approved (what deadlines are coming up? What change freezes?).

lucian1900 13y ago

The server time would drift by the latency from server to browser to start with.

antihero 13y ago
"reflect as accurately as possible, bearing in mind the technological constraints of delivering data across the internet"