Trust upholds complaint about BBC homepage clock

http://www.bbc.co.uk/ariel/22767402

by georgebashi • 13 years ago

37 59 13 years ago

bbc.co.uk

timthorn3• 13 years ago

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• 13 years ago

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

claudius2• 13 years ago

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.

lttlrck2• 13 years ago

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

thomasahle• 13 years ago

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

martin-adams4• 13 years ago

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

IanCal• 13 years 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?).

lucian19003• 13 years ago

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

akx• 13 years ago

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

PavlovsCat3• 13 years ago

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

PavlovsCat3• 13 years ago

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.

martin-adams4• 13 years ago

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

icebraining2• 13 years 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• 13 years 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)

lucian19003• 13 years 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.

radio4fan4• 13 years ago

Sure.

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

andyhmltn3• 13 years ago

I would even say 4 hours is a bit too long.

berkut• 13 years 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...

webjunkie3• 13 years ago

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

lttlrck2• 13 years ago

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

radio4fan4• 13 years ago

"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?

claudius2• 13 years ago

The article explicitly states that people expect this clock to show the correct time in the UK, which I find a somewhat reasonable assumption for the BBC.

radio4fan4• 13 years ago

So it does.

Well, in that case it's a piece of piss to implement as claudius says below.

adlpz2• 13 years ago

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.

timthorn3• 13 years ago

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

lucian19003• 13 years ago

Sadly, UK time is not UTC because of daylight savings. For example, right now UK time is one our ahead of UTC time.

icebraining2• 13 years ago

Is there a requirement to use time in the user's location? I assumed they just have to show UK time.

madaxe• 13 years ago

Did this years ago by grabbing the local time on the user's system clock (as many don't set their TZ correctly), rounding to the nearest 15 mins, and then guessing their TZ from this. 15 mins because Nepal and a few others of that ilk.

radio4fan4• 13 years ago

The problem with that in this context is that they expect it to work if the user's clock isn't set accurately.

ig13• 13 years ago

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.

mcgoooo• 13 years ago

i agree, i've actually worked at the bbc and the infrastructure that goes into these things is unbelievable and necessary.

rasur2• 13 years ago

same here. It's absolutely not a couple of servers and a bit of node, kids!

adrinavarro• 13 years ago

I just hope they're not going to get rid of caching, but instead, implement a time server and sync through JS, or something alike.

relix5• 13 years ago

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• 13 years ago

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.

ig13• 13 years ago

Because your OPs and deployment team are going to know exactly how to deploy and support something you cobbled together in a completely arbitrary way.

You obviously thought through the integration with monitoring, scaling and multiple redundancy systems so in the event of traffic spike or disaster it'll keep working without manual intervention.

That's not even touching the business logic complexity of issues like DST or leap seconds where you have to be able to arbitrarily change the clock forward or backward.

webjunkie3• 13 years ago

" timezone issues, daylight saving, latency, etc"

Didn't it say "time in the UK"?

dalore2• 13 years ago

We do have daylight savings so timezones do change.

andyhmltn3• 13 years ago

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.

shawabawa32• 13 years ago

It's on the BBC and so people expect it to be accurate.

For example, I imagine a lot of people aren't sure if/when the clocks change (daylights saving time). They check on the BBC, see that their computer time is "accurate" and assume the clocks haven't changed.

As another example, I often google "time" to check to see if my clock is accurate. If that just echoed back my local time I would feel like that was a breach of trust

martin-adams4• 13 years ago

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.

andyhmltn3• 13 years ago

Ah, that's a good point actually

dbdbdb• 13 years ago

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

Trust upholds complaint about BBC homepage clock

Related Stories