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.
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?).
Comments
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.
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?).
Actually all they need do is add a disclaimer...
It still wouldn't work if the users clock, say, ticked at double speed or not at all.
Still wouldn't work if their monitor was off. Is such a thing a real concern?
The server time would drift by the latency from server to browser to start with.