Slashdot Mirror
BBC Clock Inaccurate - 100 Days To Fix?
mikejuk writes "The BBC home page has just lost its clock because the BBC Trust upheld a complaint that it was inaccurate. The clock would show the current time on the machine it was being viewed on and not an accurate time as determined by the BBC. However, the BBC have responded to the accusations of inaccuracy by simply removing the clock stating that it would take 100 staffing days to fix. It further says: 'Given the technical complexities of implementing an alternative central clock, and the fact that most users already have a clock on their computer screen, the BBC has taken the decision to remove the clock from the Homepage in an upcoming update.' They added, '...the system required to do this "would dramatically slow down the loading of the BBC homepage", something which he said was "an issue of great importance to the site's users".
Secondly, if the site moved to a format in which users across the world accessed the same homepage, irrespective of whichever country they were in, it would be "impossible to offer a single zonally-accurate clock."'"
I'm not sure I can trust a source which says "it has been stated that it would take 100 programmer hours to fix" then quotes a paragraph stating 100 staff days. Regardless it is harder than it looks: the BBC doesn't want to get into the business of running a time server, nor trying to automatically determine which time zone any particular visitor to the site happens to be in (by, what, IP address tracing?).
No kidding!!! What do you say at this point?
For a new Time Lord!
I'm not signing anything
By the time they fix the clock, it'd be 100 days and the clock would be slower by 100 days! Then they'll try to fix again and the clock would be slower by 100 days again! ....ad infinitum...
Better to break that cycle by not embarking on this journey!
This is how I would have done it too, but then I started to think whether the JavaScript incremental timing would be accurate enough. So maybe you want to add an extra synchronization every 15 minutes or so.
So your algorithm for determining the time on the local computer is
local time = (local time - remote time) + remote time
?
You realise that simplifies to:
local time = local time
No kidding!!! What do you say at this point?
It is harder than that, ntp is hard. ntp takes hours to stabilize before it will believe it has a decent idea of the time.
How do you know how long it took to get the time request from the BBC over http?
Do you think you might get two side-by-side PC's showing different times (out by 10 seconds) depending on link contention when they made their request?
BBC cannot solve this problem.
blog.sam.liddicott.com
Considering that cheap spammy ads are able to determine your location so they can offer HOT, SEXY LADIES IN YOUR AREA, I think the BBC can manage.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
The BBC:
http://www.bbc.co.uk/news/entertainment-arts-22768861
No kidding!!! What do you say at this point?
GMT, that would be the wrong time even in the UK.
It took one large Luxembourgish bank nine months to change SUPPORTED_OS = MAC into SUPPORTED_OS = Linux32 in a configuration file in a jar named LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar (yes, they did indeed accidentally put the Mac config file into the Linux jar... it's that stupid...)
Another bank is celebrating the first year anniversary of this same bug right now as we speak :-) (unfixed yet, of course)
Reason for the slowness (in both cases): when fixing such a mixup, according to their procedures, the entire test suite (... which incidentally, didn't catch this bug in the first place...) needs to be re-run, and this takes weeks, and so they shy away from the expense.
So we end up in the paradoxical situation where the presence doesn't reduce the number of bugs seen in production, but actually increases it. Rather than catching bugs early, the test suite instead perpetuates existing bugs...
The situation is crazy and I have every sympathy with the Beeb. The clock design itself is very nostalgic for those of us of a certain age who have grown up with the BBC. They naturally created a simple clock that reflects the user's local time. A handful of morons who cannot set their computer's clock properly complained that the BBC's clock was inaccurate. The BBC cannot be expected to implement a global solution which cannot rely on the local host having any accurate time information and takes into account time zones, geographical location etc even if the issue of running an accurate server-synchronised clock is trivial. Also note that everything they do is heavily scrutinised by rabid right-wing politicians and licence-fee payers. My only gripe with the Beeb is that that it's acquiesced to these stupid complaints and withdrawn the clock rather than telling the complainants where to go.
Why show the local time on a web site? The gripping hand is, aside from being a cute widget, there's little reason for a clock to be there.
No kidding!!! What do you say at this point?
There are several things involved:
Firstly, they need to get user's timezone. There are javascript methods to do this, but are not always reliable, especially if they don't want to depend on the client having javascript support. Of course, they could always just ask the user to pick the timezone, so that issue could be solved. E.g. Formula 1 solved it nicely, though I am not sure which method exactly they use (their javascripts are not obfuscated, but I can't be bothered).
Bigger issue, in my opinion, is showing exact time. Assuming their servers all keep exact time and that everybody is happy with their definition of the exact time (which is a big assumption to begin with), BBC would also need to take into account latency between server and client. E.g. it takes about 1/3 or 1/4 of a second for me to load a single random page with a GET request from BBC.
For an example of pain it takes to give users correct time, visit The official U.S. Time page. It's a java applet, presumably because anything client-side can't be trusted to actually count a second as a second. Granted, that page is ancient, but you can still see that it's not really trivial.
Not seeing it here in Australia. Maybe I have to browse anonymously.. or maybe us Aussies are being cut off at last. No more allowance from auntie!
http://michaelsmith.id.au
Or they could just link to http://wwp.greenwichmeantime.com/, which does not ONLY display GMT, but times for other time zones/daylight savings schemes as well, along with some other country-specific information. It syncs every 15 seconds or so with their time server, and counts down the seconds using JavaScript (it looks like), which is accurate enough for me to set my watch to every now and then, it required.
Free, as in your money being freed from the confines of your account.
C is for Corporation. It stopped being a Company at the end of 1926.
Gaaaaaaaahhhhhhhhh. I thought this was a website that was supposed to be populated with technical, computer literate people, even programmers.
The end user requirement: "Show the time"
They mean "Show the correct time for my current location"
This is easy: Every (ok, perhaps there's someone still using an old IBM PC computer where you have to set the clock at boot) browser is running on a machine that has a local clock. So we'll use it to display the time.
Some end users then start complaining that the time on the BBC website is wrong.
There's two obvious reasons for this: 1. The user has taken the iphone/ipad whatever on holiday and haven't updated the timezone or 2. Their local clock is just plain wrong.
OK. So we've now established that the end user is incapable of correctly determining and setting the correct time and timezone on their machine. So we, as a programmer, have to do this for them. Cookies, asking the user, etc obviously aren't going to work. If they cannot get their own clock right then they're not going to get the website configuration right either.
This is hard, hard, hard to solve. IMO it's impossible - what do you do about people coming through proxies in different timezones?
The BBC have made exactly the right decision - the old solution was the correct one. PEBKAC. TPTB have decided that the correct solution wasn't good enough. So don't waste any more time or money trying to hack together something just to satisfy end user requirements that are fundamentally broken. End users can use the clock on their machine anyway and they won't complain to the BBC if it's wrong (presumably they complain to Microsoft instead)
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
Now, I know that some people have more time than brains on them, but whoever reported this sure must have taken the cake. High level exec or marketing/PR? Where does the waste of precious oxygen sit that considers this something the BBC programmers' time should be clogged with?
Some people just have no reason to exist and waste precious office space, so they have to notice something as important as this and cause a huge stink about it as if anyone but them cared. "I am a nuisance, hence I exist" seems to be the creed.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Man, I wish there were no such thing as a "show the local computer's time" function. There are so many websites that should damn well know better that do this. Even sites for organizations that are responsible for keeping accurate time pull this crap. Timeanddate.com does a fantastic job, I've no idea why it can't be done elsewhere. Oh, right - 100 hours to fix it and that's not in the budget.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
It seems quite feasible to create a JS lib that makes a request over HTTP to a server running some time module and receives the exact value in response. The JS could provide APIs to show that time and calculate various timezones. About the trickiest thing would be dealing with the roundtrip delay of the request but a few headers recording the client and server's response time would take care of that just like they do for NTP.
Of course this is true when you see a clock in the picture, but when I tune to the BBC and press the info button on my remote, I still see the overlaid clock in local time.
And when I press the EPG button to see their schedule, I see the schedule expressed in my local time. So "the nine o'clock news" airs at 22:00.
This is possible because this data is all transmitted relative to UTC and my receiver translates it to local time. And it only works because I cared to set
the timezone for my receiver when it went through its initial setup wizard.
What they probably are worried about is the viewers/users who do not have things like this correctly set.
After all, when your PC clock is not correct and you are on internet, you must have done something wrong. Probably set the timezone incorrectly.
(home versions of windows are by default synchronizing their clock to time.windows.com and Apple stuff probably is no different)
And why would they waste time an effort over something so ultimately pointless? It's actually amusing hearing everyone rip on the BBC for not wanting to waste money on a worthless webpage clock.
The scheduled content is only available in the UK, where a single timezone applies. For example the iPlayer is unambiguous about the current time because there is no ambiguity about what time zone the viewer is in.
No kidding!!! What do you say at this point?
GMT died in 1972, so can we put this to bed already please?
100 person days have been spent reading and commenting on the ./ article. (101 now)
So your algorithm for determining the time on the local computer is
local time = (local time - remote time) + remote time
?
You realise that simplifies to:
local time = local time
No it's not, it's:
Thread 1:
while(1){
delta_t = remote_time - local_time;
sleep(5 mins);
}
Thread 2:
while(1){
display_time = local_time + delta_t;
update_clock(display_time):
}
This actually simplifies to:
display_time = local_time + (remote_time - local_time)
or
display_time = remote_time
But with the advantage of only polling the server every 5 mins, not every time you want to update the clock. 5 mins is probably to frequent for the application, but in the correct order of magnitude.
Most Damage is done by people who are AWAKE
The BBC home page has just lost its clock because the BBC Trust upheld a complaint that it was inaccurate.
How in the world was it inaccurate? If it showed the user's time, and the user's connected to the internet, it is the correct time. Unless there's some OS I don't know about that doesn't use an online time server to set it's own clock.
Given the SNTP network exists and [is] in use by lots of machines there really doesn't seem to be any need for the BBC to reinvent the atomic clock.
Yeah, no kidding. Why is this even a story?
-- sudon't
Air-ride Equipped
Millions of staff days lost by the debate on Slashdot, Reddit etc.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Wow what a nothing issue. It's not accurate because it's tied to the machine I view it from??? Then it's the fault of the end user. The BBC have taken the correct approach to this issue they've decided we're too stupid to have a clock!! The scary thing is I suspect that in general they are correct.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Require IE6. Install an ActiveX control. Pull the time from the local computer. Done. Everyone's happy.
Time is easy. Until you have to bother with it in your code. Then it becomes a nightmare.
The BBC domestic services only use GMT/BST (Greenwich Mean Time in winter, British Summer Time in summer). One time zone. Although they can be received in other countries in other timezones - for example BBC1 and BBC2 domestic TV channels are provided on cable in the Netherlands - no reference is made to those other timezones.
The BBC's overseas services primarily use GMT but are broadcast regionally (e.g. "Middle East", "West Africa") where they may optionally mention secondary timezones on-air. For example, the BBC World Service's South Asia radio broadcasts may say "It's eleven hours GMT, fifteen-thirty hours in Delhi."
The BBC has no European radio service any more. European relays of the BBC World Service, including the relay on Digital Audio Broadcasting (DAB) radio inside the UK, use the African stream. This primarily uses GMT but occasionally additionally references a secondary timezone in a major African city such as Johannesburg or Lagos. There is a specific African breakfast news programme on the BBC World Service's African stream, presented jointly from London and Johannesburg, tailored around the morning hours across several African timezones.
Live presenters on the BBC World Service may also announce the time as simply "minutes past the hour" without referencing which hour they're referring to, for example "It's twenty minutes past the hour". These are particularly prevalent for African streams. These "minutes past" timechecks are avoided in regions with timezones that are offset by 30 minutes, such as India.
BBC overseas TV timezones fit into two categories; regional and worldwide. Worldwide services such as the BBC World news channel or BBC Entertainment do not usually reference the time as spoken word, but instead represent the time using on-screen graphics. The graphics will show GMT plus a selection of 3-5 timezones appropriate to the region the stream is broadcast to. For example, the European stream of BBC World will use GMT, Central European time and Moscow time. These are typically shown as full-screen text announcements for future programming (e.g. "Hard Talk, Mon-Fri at 08:30 GMT, 10:30 CEST, 12:30 Moscow" for the European stream). Where programming is shared between regions, they may either use opt-outs for regional time displays or use a more general subset of timezones (e.g. GMT, EST, India; very rarely, GMT is omitted in favour of CET).
Regional overseas TV services such as BBC America or BBC Arabic will use whatever timezones that region uses and will cope with it just like local domestic services. They will not generally use GMT.
Andrew Oakley - www.aoakley.com
I have never understood why so many people are so keen on putting a clock onto a website. Everyone has a clock.
Bogtha Bogtha Bogtha
the BBC Trust upheld a complaint that it was inaccurate
OK, so it's inaccurate - that just puts it in the same class as every clock in the world, excluding the global standards (and even they don't agree when you get down to small enough time divisions).
This is a systemic problem with the Beeb. They take every complaint or criticism "personally". If a programme draws a few complaints then an apology gets issued. If an interviewee uses a "bad" word on live TV an apologist instants says sorry. The corporation seems to have this view of itself as being infallible and that every mistake is the cause for some self-flagellation.
Although I can see why they have this view: they are publicly funded from a virtually compulsory source (have a TV? you gotta pay) and have made a whole string of astoundingly stupid blunders in the past - and this pronouncement is just one more. However they really should build a little self-confidence and learn to stand up and say to their critics "screw you - yes, we make mistakes ... live with it".
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Wow what a nothing issue. It's not accurate because it's tied to the machine I view it from??? Then it's the fault of the end user. The BBC have taken the correct approach to this issue they've decided we're too stupid to have a clock!! The scary thing is I suspect that in general they are correct.
The point is that they've done this in response to formal complaints... which means that yes, in some cases the users *are* too stupid to have a clock, and not only that, those same stupid people are willing to kick up a fuss about it and raise complaints.
(Spudley Strikes Again!)
Just went to bbc.co.uk from New Zealand...no clock, where are you browsing from?
Before the days of affordable accurate clocks [1], the BBC clock [2] kept the country in sync. Accurate timekeeping is vital for radio and TV, so it's no surprise the BBC takes its timekeeping seriously.
1: first, receivers for time signals like DCF77, then NTP
2: in the shape of the time signal on the hour at the start of the radio news, and various clock displays on TV
Combine 'precision master source' from a 'BBC time' server with local time as set by the user. So for example BBC time might be 14:12:03 while the user is somewhere the other side of the Atlantic and their local clock says 10:10:56. The combined display would be 10:12:03. ie the hours sourced locally while the minutes and seconds come from a basement in Broadcasting house. OK this doesn't deal with latency etc but that's not a big issue is it?
That would be such a lousy design as to be essentially useless. Offset would drift with time, since you are never resyncing and not correcting for local clock drift in between resyncs.
There is a lot more to determining current UTC than querying a remote server once. Little things like, um, propagation time, which can be substantial depending on internet connection and routing (just imagine the guy on satellite or dial-up). Anyway, thanks to people who actually knew what they were doing decades ago, it's a solved problem. Look up NTP sometime. I bet you could implement a pretty good NTP implementation good to a fraction of a second in Javascript for the poor Windows saps. Of course, anyone with a real OS is already running their internal clock synced via NTP.
Then converting UTC to local time, should you so desire for some weird reason (just about every piece of graphic interface computer equipment already has a local time clock on screen; not so many have a UTC clock, so that would be far more useful) is merely a system call, even in Windows.
What the BBC said was that they would find it difficult and expensive to accurately show the time at the user's location, when the user's time settings were wrong.
This is roughly how I would do it:
Wouldn't that work?
alias sudo="echo make it yourself #" ; # https://pipedot.org/~stderr & http://soylentnews.org/~stderr
If their clock is set wrong on their pc... How much can they REALLY care about an accurate time on some webpage?
Maybe that's exactly WHY they care about an accurate time on some webpage.
"I think my PC clock is wrong, but no worries, BBC has a good, old trusted time service, so I'll just set my PC clock according to their homepage..."
Of course BBC can solve this problem. Other sites solve it. They all agree within one second of my own system's NTP-synced time.
Try man ntpdate. With the right option it will set your clock one time post haste. It's intended for use at startup, when the clock is discontinuous anyway. Then ntpd can keep it synced.
You could do the equivalent of ntpdate when you load the page, and the equivalent of ntpd while the page is displayed, with the clock updating.
Yes, what NTP does is very nontrivial, but it's a long-solved problem. Pulling the NTP levers using the already-compiled executables is not hard, and rolling your own implementation is not exactly rocket science, since the protocol definition is exhaustively defined and open source implementations are freely available.
I'm not going to do the complete design for you, but just consider, why would they use HTTP?
time.eprci.net. It initializes with the server-side time (the server clock is synced via ntpd) and then uses JavaScript to just increment second-by-second. It's a couple dozen lines of code in PHP and JavaScript. I wrote that in half an hour years ago.
Liberty in your lifetime
The decision by Microsoft set the system clock to local time, rather than UTC makes me give thanks frequently that the USA has timezones. I hate to think what abhorrent mess would have been created if the USA had a single timezone.
IMO, the quick fix is to use the time on the viewer's machine to determine the approximate time (time zone) but to use the time coming from the server to determine the exact minute/second +/- network latency (ignore network latency for now if that gets complicated).
You don't need a clock project to do this. I wonder really who wrote that pile of trash to begin with, but it could also be as simple as clock drift or not using NTP for example to keep everything sync'd up.
There are thousands (okay hundreds) of examples in Ruby, Java, C# and Javascript out there to get the time and adjust it for timezones including offests for Standard Time / Summer Time or Daylight savings etc.
This is all part of I18N and has been for years and I can't believe it's this hard for the BBC, wait it's a public/private thing so maybe James May can fix it with some glue and a spanner.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
1. Geolocate the IP, show the local time and mark it with a timezone identifier/city
2. If geolocation data is not available for IP, show UTC time celarly marking it as such
3. Put a button on the side of the clock to acquire the user's coordinates if a GPS is available, mark the timezone as GPS-determined
4. If GPS is not available and user pushes button, use the JS new Date().getTimezoneOffset(), mark the timezone as OS-determined
There are corner cases where this will not work, but this is good enough for 99% of the users.
The user is behind VPN/Proxy? If he cares about the correct local time, he'll push the button.
The user has no GPS and wrong OS timezone? Too bad.
Sometimes the HOT, SEXY LADIES are in the area of the airport I passed through a week before. Imagine waking up in Australia with jetlag after flight with a stopover in Singapore and trying to figure out what time it is!!
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Offset would drift with time, since you are never resyncing and not correcting for local clock drift in between resyncs.
And just how long would you expect to keep a single webpage open for?
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
You have missed the point. NTP does not account for inaccurately set timezones. It's not the "tick-tock" that's the problem here, it's the timezone.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Given that the vast majority of computers already display their time on the screen; it is reasonable to assume the only the purpose of an additional clock on the BBC website is to validate its accuracy.
n.b. a large proportion of the population grew up setting their watches to the BBC's pips, it is also natural to consider them an authority on the subject.
Actually, the radio streams are world wide to my knowledge.
Change is certain; progress is not obligatory.
Somebody showed up at some desk with a complaint (which has been upheld by the BBC trust and thus needs to be dealt with) about the clock on the website not being correct when the users local clock is off. Now the best thing to do in that case is to make sure you loose the clock asap, because whining about the clock on the website has just become a valid complaint. A clock on a website is one thing, making sure a clock on a website is always accurate for all clients, even when they screw up their own system clock is another. And it may actually take a 100 days if you actually have to bother with testing it in all sort of scenarios, time zones, browsers en daylight savings time etc.
But either way, it not worth the effort. Removing the clock is the only correct response when people complain about the clock being off when there own system clock is actually wrong.
And it may actually take a 100 days if you actually have to bother with testing it in all sort of scenarios, time zones, browsers en daylight savings time etc.
Send UTC and let the browser format and adjust to the local. VERY easy, almost no testing.
They report news, and do it well.
It is virtualy impossible to, 100% of the time to 100% of visitors, get the time right. The computers time can be wrong. A laptop set to EDT on a business trip tp LA will have the wrong time and the user won't adjust it because he's only going to be there a day or two. Besides, he or she may want to quickly see what time it is at home. How on earth could you adjust for that? IP addresses registered in one time zone may be servicing another, so geolocation of IPs doesn't work. What's left?
It *is* a tough problem and 100 days is probably right and I bet they still won't ever get to 100% of the time, general computers and laptops don't have the technology to maintain locationally accurate time. Removing the clock is a "simplification" that removes an unnessisary work load and no user will be harmed and the service will not be affected.
When the BBC implemented this clock, they were pushing forward technology by being the first large website to use HTML5 canvas. Yes, thats right, there is no flash in that clock...
They didn't make a big fanfare about it, they just implemented it.
Now that canvas is widespread, I would prefer they go push other bits of technology forward.
I'm trying to understand why setting up a script to echo a clock synced to an international time server (using timed) is an unacceptable fix. I'm a shitty programmer myself but I could implement that in a couple of hours.
Does the BBC think they have reinvent the wheel and buy some Microsoft-blessed solution or something?
Sure, because if you aren't allowed to depend on the users setting their local clock correctly you clearly will be allowed to assume their local timezone is correct...
And apart from not being able to use the local time-zone, check their supported browsers list, they need to make sure it works in IE 5.5, Firefox 2, Opera 9 and Safari 2. Testing alone is going to be quite some work. Especially when you want to be sure it works correctly when somebody watching during a daylight savings change etc. It might not be especially hard, it might not take a 100 days, but it is going to be a lot of work.
The way I read it this problem is just the latest edition of a stupid-user problem. They don't understand how things on a computer works so it's magic, and therefore since it's magic (and not mechanical) it should be right 100% of the time. Putting a label on the clock isn't going to help because they don't know what local computer time is. It could actually make it worse as then they have an association that somehow the BBC is involved in their local computer time. If you've ever had to do support you should know what I mean...
The problem (as described in comments below) is that this likely arose because the user did not accurately set their own local time... most probably including incorrect timezone. If the user's own computer time details cannot be trusted, you are basically lost, as it will be impossible to tell what timezone the viewer is in.
Okay, so in that case ignore the user but that depends on if it is server side or host provided. If you want to use "world" time standards I wouldn't rely on what the system displaying the information says in that case. I still think James May can fix it in a new BBC series "Man Lab: Web Programming"
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I am sure BBC News will blame the inaccuracies of their home page clock due to the devastating effects caused by Global Warming as they blame everything wrong with the planet on that ol' scapegoat. Something about excessive Carbons in the atmospheres interferes with the correct calculations of the Maths involved to tell Times.
Also if you can't report accurate time then what does that say about your news reporting abilities?
Finally, as with all well oiled government run tax based enterprises, 100 days to fix an online clock in the 21st century would actually be quite an amazing feat, but probably would cost billions.
I haven't thought of anything clever to put here, but then again most of you haven't either.
Comment removed based on user account deletion
You're right getting an accurate time is easy... the hard part is figuring out a timezone. geoip is unreliable due to proxies, so how else are you supposed to guess which timezone the user is in?
1) Okay, assuming that geoip is not accurate then use multiple services on a miss. I use freegeoip.net for example.
2) Javascript.. Date().getTimezoneOffset(); Will give you the offset in minutes from UTC. This assumes the user has at least set his / her timzeone correctly. Apply that to the UTC time from the server and you can display the local time (no DST applied however)
3) If you want to be more elaborate here's another. http://www.codeproject.com/Articles/58728/JavaScript-code-to-determine-when-DayLight-Savings as an example.
My choice is to not use the local system time/timezone at all. Present the News clocks of the world and pick your cities:
New York London Paris Moscow Bejing Tokyo Los Angeles as an example and forget what the user has set.
My point is: Time has been done to death in multiple programming paradigms and languages. Pick one. If you assume that the user is dumb enough not to set their own time, again you could use any one of the GeoIP services and if you come up with a blank you can also ask them "Where are you? So we can give you accruate local information." If they refuse, who cares and don't display it. But always take your base UTC time from your servers where you can at least control that aspect of the time presented.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
If one minute is sufficient, they are free to use this code, which I wrote years ago. (I don't remember how long it took me to write, but it was less than 100 days).
Do you care about the security of your wireless mouse?
They're supporting IE 5.5? Well, there's your problem.
Also the international component will make it inherently inaccurate, eg: Oz to UK is a 1/4 sec ping on a -very- good day.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
If you're just setting your watch or the kitchen clock, +/- a few seconds to the minute is good enough. You want down to the second / millisecond / microsecond accuracy, go somewhere else.
.
Prisencolinensinainciusol. Ol Rait!
The scary thing is I suspect that in general they are correct.
As much as people may be too stupid for not using their on-board computer(often set with internet time, ensuring accuracy and making BBC 'time checks' irrelevant), the way BBC is characterizing the task of providing an accurate, global clock is just plain wrong. It is actually not that difficult of a task if you look at what needs to be done.
1. Grab time from NTP (possibly scrape it from a NIST website or something)
2. Translate to local time(user log-in with TZ prefs, or default to GMT)
3. Display it.
If the coders they have working on the site can't manage that, they sure as fuck shouldn't be working for one of the world's largest news agencies running their website.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
No, the problem is not just the timezone, it is the tick tock problem too. The time zone problem is very easy to fix by saying "GMT"
blog.sam.liddicott.com
If you want accurate time to fix the time of your watch, use the time displayed by a GPS.
It comes from at least 3 different atomic clocks in satellite and your receiver has algorithms implemented to compute the UTC time very accurately (at least much more than what a website could display).
1/4 second or even 1/2 second is probably just fine for most users. I haven't seen the clock, but I don't believe it even goes into single-second resolution. There are also more local sources for retrieving the actual current time for their server(I'm pretty sure the main time authority is in Greenwich), and the transit time shouldn't be relevant if it at least provides an accurate time from the moment it receives the request.
If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
A) you aren't taking into account the entire release process.
B) You code is useless as it doesn't take in all the possible times throughout the world
C) I would have words with you about that code if you were implementing t in a ggobal system, it's i'll thought out.
are you even familiar with mktime at all, or did you just copy some code from your 'learn html for Dummies' book?
The Kruger Dunning explains most post on
Servers taken care of. What's the BBC billing address? :)
Serious? Seriousness is well above my pay grade.
Spending as much time on the release process as it took to write the code in the first place might be acceptable. But having a release process so convoluted that it increases the work by orders of magnitude means there is something wrong with the release process.
It solved the problem it was designed to solve. And that fact alone is enough to prove your statement to be incorrect.
If you want people to take advice from you, you need to be constructive. Constructive would mean provide concrete suggestions for improvements.
I know there is not such thing as mktime in html, since it is a markup language not a programming language. That is apparently more than you know about it.
Do you care about the security of your wireless mouse?
the date formats, THE DATE FORMATS! If only everyone used YYYYMMDD.
ISO 8601, the One True Date Format. Today is 2013-06-06
What timezone do you use? Factor in that the timezone may not be correctly set in the first place, or the machine may be roaming, or accessing via a VPN.
2. Translate to local time(user log-in with TZ prefs, or default to GMT)
I've highlighted the problem that you forgot about. Stupid users will still complain that the clock isn't accurate because they won't be able to figure out how to set their preferred timezone.
Oh come now. Every PC already has a local clock. The only thing that makes sense for the BBC site to do is give you a UTC (GMT if you must) clock. It's basically a tradition of BBC radio. Do you think the BBC radio gives a rundown of every local time in the world? Or do you think it announces "bong. The time is xxx GMT"?
NTP is completely unaware of time zones. It merely syncs unix time, which no matter what the zone is a count of seconds in the epock, related to a UTC start time, 1970-01-01 00:00:00.
The gimmick is that the time presented by the BBC site can be completely independant of how accurate the PC's own clock is.
timey wimey stuff... it's a BBC specialty.
What part of `yes no` don't you understand?
B) You code is useless as it doesn't take in all the possible times throughout the world
Who cares. If the BBC clock always showed London time, it would have more value than no clock. Most people who want an authoritative clock just care about setting the minutes and seconds on their watch or computer clock, by hand. (Anyone technically sophisticated will use real protocols and a real authoritative time source.)
Socialism: a lie told by totalitarians and believed by fools.
No just show the time in the UK you furiners will just all have to start using GMT - and it would piss the french off :-)
That the french surrendered again.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
The hilarious thing about this litany of excuses is that there are several dozen 16-year-olds in the UK that could do the whole thing right in an hour. All the while mouthing-off to his friends.
"You must try to forget all you have learned. You must begin to dream." -- Sherwood Anderson
$ host ntp0.bbc.co.uk
ntp0.bbc.co.uk has address 132.185.132.130
First, that does mktime which repeats the same problem. Ie, it uses the time on the local computer, it is not going to a remote computer that has been validated to be accurate. Second, even if implemented you still need a lot of back end work to be done. Ie, testing and validating. This was a formal complaint, not a "it would be nice if" feature request.
Your technical proposals are all spot on. But, this little thing on the website has grown from a really simple piece of code that uses the local time to one that needs to one that
a) determine the timezone from geoip
b) as geoip can be badly wrong when used with strange 3G networks/proxies/gateway, determine if the timezone is *actually* the one the user is
c) when geoip fails, ask the user for their timezone manually
Knowing the amount of work involved in coding... this is sounding like their 100 day estimate is accurate. Anything less than all 3 will not fix the complaint. All 3 will need design review (copying and pasting from codeproject doesn't count as "design"), then test plans, then coding activities, test reports, verification reports... 2 people for 2 weeks = 10 days, and that is assuming there is no budgeting, and the resources are sitting around idle.
The long and short of it is: your technical proposals feel like they are adding more credence to the BBC's decision to pull the clock. Why are websites required to work around the fact the user has somehow borked the auto time sync every OS since early 2000 has shipped with?
... and it seems to be accurate.
It took a few seconds for each to respond, being I'm on the wrong side of the pond and all.
So they appear to participate in the centralized time system, that understands UTC, I don't see where their big problem is. 100 days to program a javascript clock to use their servers instead of the client machine?
I am surprised that they still do have a clock on there. Well, I never noticed when I went, but I wasn't really going to the BBC to check the time. Most people took clocks off of their web pages back in the late 90's, right along with dancing babies and blinking text.
Serious? Seriousness is well above my pay grade.
1) Clock drift in excess of a minute per day is not unheard-of.
I don't think I have ever seen numbers that high myself, but if needed, the time_diff could be recalculated more often. If the page notice a large clock drift between two calculations of the diff, it could schedule the next recalculation to occur sooner.
2) If the AJAX request fails, what do you do?
For the first calculation of the diff, you don't really need to use AJAX since the page already includes the server time in the "clock"-element. If a later AJAX-request fails, you could simply reuse the old diff and schedule a new calculation at a much sooner time that otherwise.
3) If the AJAX request hits a high asymmetric delay (not unheard-of), you'll be off by a good fraction of a minute.
You're right, I don't have a good solution for that problem. Maybe take a look at how NTP deals with it.
4) If the user can't set their computer's clock, what makes you think they can set the computer's timezone?
I don't think I said anything about the user setting the timezone anywhere, so I fail to see your point.
I did mention the "Europe/London"-timezone, but that timezone would be set by the BBC site, not the user.
5) Related to 4, what happens during a daylight savings time shift? You can't count on the local clock changing by an hour, but you also can't count on it *not* changing.
What daylight savings time? There's a reason why I'm using milliseconds since Epoch.
If you know the time in milliseconds since Epoch and you know when the transition between standard time and daylight savings occur (or any other change of offset from UTC), you can calculate the local time. You can find the transition times and offsets in the tzdatabase and do the calculation yourself or you can use the tzdata-javascript library I mentioned.
alias sudo="echo make it yourself #" ; # https://pipedot.org/~stderr & http://soylentnews.org/~stderr
> You're right getting an accurate time is easy... the hard part is figuring
> out a timezone. geoip is unreliable due to proxies, so how else are you
> supposed to guess which timezone the user is in?
On the local site, give London time, whatever zone they're in.
On the international site give GMT/UTC/whatever-they-call-it-now.
Period... end of story. What's so difficult?
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
The server I was hosting this code on of course had ntpd running from day one. The clock on that computer was accurate to within 10ms.
Do you care about the security of your wireless mouse?
The analogue display on the BBC clock is impossible to read accurately enough that you wouldn't be able to detect any delays or lag in the NTP->web-server->user chain. The BBC's problem is not a power-user problem, because power users will be using NTP directly, or at the very least they'll set their system clock against a digital display with seconds readout....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
If that's London time (including daylight saving when applicable) that's fine; the 10 O'clock news will be on when the website says it's 10 O'clock, even if I'm in Budapest.
The line on the schedules page to show "now" seems to work like that.
http://www.bbc.co.uk/tv/guide/bbc/london
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Use the same technology that blocks iPlayer outside the UK to decide whether to display Summer Time during summer (in the UK) or all UTC all the time (outside UK).