
Trust upholds complaint about BBC homepage clock - georgebashi
http://www.bbc.co.uk/ariel/22767402
======
ig1
People surprised by the 100 days requirement have presumably never seen the
type of infrastructure required by a top-100 website or had to deal with user-
time issues.

Having an independent clock means turning off caching, which is a big deal
when you're serving millions of page requests.

Not to mention having to deal with timezone issues, daylight saving, latency,
etc. This stuff is hard.

~~~
relix
Just add some javascript to load the time from a different server after the
cached version is rendered. Build a simple service in node.js, ruby or java to
return a json datetime, use that as the endpoint to load the time from. This
is not rocket science and should not take 3 months to build, even with all the
caching involved.

Edit: I just checked the headers that are sent along with any request to
bbc.co.uk, and the response already includes the current datetime. So
basically they don't even need to implement a time server anymore, but just do
an Ajax request to document.location, and read the Date header on the result,
to get the accurate time. They can just upscale their servers a bit to handle
the extra requests (or implement an empty-response URL). Why would this take
100 days again?

Edit2: Sample code here: <https://news.ycombinator.com/item?id=5825319>

~~~
JonnieCache
This is the BBC, not some startup in a garage with a couple of EC2 instances.
It's the busiest website in europe, and it's publicly funded. If they just
threw up external node services whenever they felt like it there would be
chaos.

For example, whenever there's a major news story they see traffic spikes that
would make you weep.

Internally on the other hand, where the stakes aren't so high, they make heavy
use of rails, node, go and all that cool stuff. They know what they're doing.

Check out this list of some of their machines, from part of their monitoring
system which is for some reason left open:
<http://support.bbc.co.uk/support/rrd>

Here's is some data about their peering:
<http://support.bbc.co.uk/support/peering/>

Yeah that's right. Peering.

EDIT: you're right that they could probably implement this quite easily, but
the point is they can't just throw up an agile solution at the scale of the
BBC, even if it seems safe.

~~~
relix
The point is that this could be solved by a solution that is completely
external to their current infrastructure, meaning they don't even have to mess
with any integration or legacy code. Agile in this case seems perfectly
suitable because they can easily have a fallback when the server doesn't
respond to a "time"-request, that falls back to the current state (i.e. use
client-side time). So we've got the perfect storm of no integration with
current systems, tiny overhead on requests (it's basically an ECHO server),
unimportant feature and easy fallback.

In fact I have an enterprise plan to sell them that does exactly this if they
would like to externalise this problem.

------
claudius
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.

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

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

------
radio4fan
"The corporation also added that it would take around '100 staffing days to
make the changes involved in switching to an independent clock'."

I'd like to see how they're going to implement that without relying on the
user's time settings in some way.

Sure, they could get the system timezone offset, but that's not really any
more safe than using the system clock.

GeoIP lookup? Surely location services won't fly because of the scary browser
message.

Any other ideas?

~~~
adlpz
Just set it up to the on-load time in UTC. It's the BBC after all, put it in
London time and say so somewhere in the footer.

~~~
timthorn
But London time isn't UTC! We're BST at the moment, and GMT in the Winter.

~~~
rwmj
But we _could_ stay on UTC all year. Why force everyone to get up one hour
earlier in summer? If people want to get up, they can do it themselves. Leave
the rest of us in peace.

~~~
timthorn
Even then, and with my pedant's hat on, GMT !== UTC - they can vary.

~~~
adlpz
Goddamn adjustment milliseconds being all annoying.

------
timthorn
That clock means a lot to those of us in the UK of a certain age - it does
create an emotional link to the website by being there.

~~~
jumblesale
Yeah, that clock is more than just an inaccurate way of telling the time, it's
an iconic image from the BBC's history.

------
lttlrck
'100 staffing days' to make the change? That erodes more trust than the
'factual accuracy' of a decorative clock.

------
dbdbdb
"A member of the public complained that the clock on the homepage merely
reproduces the time stored on an individual computer's internal system,
whether it's accurate or not."

Problem exists between computer and chair. Some people need to get a life.

------
andyhmltn
How does this 'undermine trust'? If you're basing your scheduling based
exactly on that clock expecting the exact time in London, then you are doing
something wrong.

~~~
martin-adams
Often when we switch from GMT to BST (one hour ahead) I have to Google the
time in the UK (because of Apple's trouble in the past with daylight savings,
I can't trust my phone).

It would be reasonable to expect someone to go to the BBC homepage and see
what the current time is after the daylight savings switch, and wrong to find
the time was incorrect due to their PC not being configured correctly.

~~~
andyhmltn
Ah, that's a good point actually

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

~~~
icebraining
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.

~~~
lucian1900
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
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

------
akx
Wait... 100 staffing days? How is that even remotely possible?

~~~
PavlovsCat
If you put 100 people into a small room, it will take them 24 hours to solve
this problem. With less people, or a bigger room, it can be done faster,
simply because having more than enough oxygen and space for your limbs helps a
great deal with the process.

At least I _think_ that's what it means...

~~~
PavlovsCat
Haha, what's the downmod for? Because it was a bad joke, because it was a joke
period, or because it actually went over the head of someone? HN, go out more.

~~~
perbu
IMHO, because we shouldn't have snarky jokes here. This isn't /.

~~~
PavlovsCat
Is that from the posting guidelines or just random snobbery? Anyway, unlimited
unaccountable anonymous downmoderation is exactly that, a snarky joke that
never ends. And in that respect, slashdot is dancing circles around HN.
Respect your elders, how about that :P

