LOST IN TIME....
if this wasn't such a serious subject it say its just one of those things.
Unfortunately it isn't.
70 London 999 calls lost due to clock-change IT glitch
The London Ambulance Service trust has confirmed that more than 70 emergency calls were not visible to staff due to a technical fault caused by a switch from British Summer Time last year. A control room IT glitch led to the loss of the calls in October last year, the service said. According to an article in the Health …
-
-
Monday 20th February 2012 08:26 GMT GitMeMyShootinIrons
Re: LOST IN TIME....
I second that. Of those 70, all it would have taken is one permanent serious injury or death directly related to this and I think this wouldn't have been a relatively minor article on a tech website six months on.
They were lucky the dice roll went in their favour. This time.
-
Monday 20th February 2012 09:09 GMT cocknee
Re: LOST IN TIME....
and it's not the first time that records have been lost
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las/lascase0.9.pdf
Shitty software development in both cases - you'd think that the LAS would be so much more careful after the 1992 debacle. DST is used across the world whether you like it or not and systems are designed to cope with it.
Where was their testing? Who the bloody hell is responsible for this software?
Heads should roll
-
Monday 20th February 2012 14:20 GMT Anonymous Coward
Re: Re: LOST IN TIME....
>Who the bloody hell is responsible for this software?
Assume that's rhetorical, but just in case it's not - Northrup Grumman, US arms manufacturer. The parallel with Lockheed Martin getting the UK Census is astonishing! Basically these are THE two US spy plane/stealth fighter/bomber manufacturers (though Boeing is increasingly involved. Wonder which UK software/databases Boeing pwned.)
-
-
Monday 20th February 2012 08:29 GMT jake
Eventually ...
... we will figure out that resetting clocks twice a year is pointless.
And probably contraindicated.
Seriously, has "spring forward, fall back" ever been anything but a government imposed inconvenience on damn near everyone?
It sure as hell never made any difference to my planting schedule ... Nor my father's. Nor my grandfather's. Nor my greatgrandfather's. Nor my greatgreatgrandfather's. And I have (most of) their planting diarys going back to the 1830s.
Pick a local "high noon" at the summer solstice, and be done with it, for Gawd/ess's sake ...
-
-
-
Monday 20th February 2012 09:21 GMT Blofeld's Cat
Re: Re: Re: Eventually ... (@Evan Essence)
Well to be pedantic, the amount of daylight varies with latitude - hence the midnight sun and constant night at the poles.
This effect is definitely noticeable when comparing the North of Scotland with Southern England.
Or California with Alaska. for that matter.
-
-
This post has been deleted by its author
-
-
-
Monday 20th February 2012 09:50 GMT Evan Essence
Re: Re: Re: Eventually ... (@Evan Essence)
I carefully said that people in Scotland want to keep summer and winter time (which I presume they do). Don't argue with me, argue with them. I'm saying that since they're more affected (in summer as well as winter) I'm quite happy to accede to their wishes.
-
-
-
Monday 20th February 2012 12:20 GMT Wize
No need for daylight savings these days
Lots of people have flexi time. If they want to get up earlier so they can go home earlier, they can.
If schools want to change their start and finish times to match up with local lighting, then let them.
Why not stick to GMT all year round?
We will have to educate the muppets who think that going to Summer Time gives more sunlight in a 24hour period though.
-
Monday 20th February 2012 15:35 GMT JDX
Re: No need for daylight savings these days
>>Lots of people have flexi time. If they want to get up earlier so they can go home earlier, they can.
Unless they have children. You're still doing the school run in the dark for several months, which is depressing for all concerned
>>We will have to educate the muppets who think that going to Summer Time gives more sunlight in a 24hour period though.
I think you're falsely attributing that thought to people who don't actually hold it. Even thickos know the clocks change so we get more of the daylight, even if they don't understand why it works that way.
-
-
-
Monday 20th February 2012 09:13 GMT Blofeld's Cat
Re: Eventually ...
It's already a 24 hour world as far as a lot of people are concerned. My own start and finish times vary throughout the year as I need daylight (and reasonable weather) to do my job.
On that basis adjusting for summer time and different time zones is not really a problem.
The trouble is that most big institutions haven't realised this yet.
The tax year still starts on the old New Year's Day - and that changed in 1751.
-
Monday 20th February 2012 09:41 GMT jake
Re: Re: Eventually ... (@ Blofelds Cat)
The problem is that It's NOT a twenty-four hour world.
Remember, there are 365.25ish days in a year ... The math(s) gets ugly.
However, noon is still noon regardless. And it doesn't matter what the gubmint tries to proclaim, my critters & veggies follow the sun. Not your tax year.
-
-
Monday 20th February 2012 09:25 GMT Peter Jones 2
Re: Eventually ...
We should be the first country to use UTC permanently. It would be a minimal disruption for us, and might lead the way to every country using it and the abolition of time zones.
But the obstacle is convincing people that 9am doesn't need to be the time to start work every single day of the year. And it really shouldn't be that difficult. Imagine you work 9-5 every day. Then your boss says "From next week, we need you to start at 8, and finish at 4." What would you do? Set your alarm an hour earlier. Everyone would be able to cope with this a lot easier than the current system of turning every clock in the place forward or back (and missing one, or going the wrong way, or forgetting entirely) and which could be staggered by individual companies, schools, etc.
Benefits include less of a peak during rush-hour traffic, no need for clock reconfiguration twice a year, and finally ending the debate over "putting the clocks back makes it dark on the school run. So start school later in the day, you damn idiot!"
-
Monday 20th February 2012 09:43 GMT Kubla Cant
Re: Re: Eventually ...
I've always been in favour of year-round UTC (or GMT). But the way you describe adjusting the working day makes it sound like a tremendous hassle.
How many people really need to align their working day with the hours of daylight these days? Those who really have to, I suspect, do what they've always done: start earlier or later and finish earlier or later. For the rest of us, who spend the day in artificial light regardless of outside conditions, there's no point in the change.
-
Monday 20th February 2012 14:08 GMT ChrisC
@Peter Jones 2
I don't think everyone would be able to cope as easily as that, especially not if (as you seem to be implying) the shift from 9-5 to 8-4 working wasn't imposed across the board by every single company, school, organisation and other entity whos working hours interact in subtle and not so subtle ways throughout the day.
-
-
Monday 20th February 2012 10:03 GMT Kubla Cant
Re: Eventually ...
My work activities are such that daylight isn't important (or even, sometimes, visible). But I have my own story of the stupidity of DST.
For 20 years or more I cycled through central London to work. People used to say "You're brave", and I would answer with a self-deprecating smirk. When I moved to the country, I thought my cycle journeys would be safer and more enjoyable. They were, until the clocks changed.
The mornings, of course, were OK. At this time of year it gets light at about 6:30 in middle England. But it gets dark well before home time. Try cycling across the Cambridgeshire fens in the sort of darkness that I could never have imagined when I was a city dweller. The roads are narrow and bounded by ten-foot ditches. Many of the motorists are people who, as a result of inbreeding, only have a few thousand brain cells, and those are fully occupied rolling fags and tuning to Radio Dickhead. One night I had two near-death encounters (even with five lights on the back of my bike**) and I gave up cycling until BST.
** As a letter to The Times pointed out last week, many drivers are unable to see a bike when it's lit up like a Christmas tree, but they have no trouble spotting lots of cyclists without lights.
-
Monday 20th February 2012 08:47 GMT Anonymous Coward
Hire dumb developers - get dumb software
As long as even "big companies" try to hire dumb developers because they are cheaper, all you get is dumb software. Managing summer time switches in 24x7 app may be tricky (especially when you fall back because you have duplicate times) but that's what makes the difference between a smart developer and a dumb one (maybe from a country where there is no summer time switch....). And about companies like Northrop-Grumman, remember what happened to F-22s when they crossed the Internationa Date Line for the first time...
-
Tuesday 21st February 2012 08:25 GMT cloudberry
Re: Hire dumb developers - get dumb software
OK, I'll bite. What did happen to F-22s when they crossed the International Date Line for the first time?
Very well, then, I'll Google:
http://www.dailytech.com/Lockheeds+F22+Raptor+Gets+Zapped+by+International+Date+Line/article6225.htm
DailyTech, 26 Feb. 2007: Lockheed's F-22 Raptor Gets Zapped by International Date Line
Six Lockheed F-22 Raptors have Y2K-esque glitch of their own over the Pacific
Lockheed's F-22 Raptor is the most advanced fighter in the world with its stealth capabilities, advanced radar, state of the art weapons systems and ultra-efficient turbofans which allow the F-22 to "supercruise" at supersonic speeds without an afterburner. ...
But while the simulated war games were a somewhat easy feat for the Raptor, something more mundane was able to cripple six aircraft on a 12 to 15 hours flight from Hawaii to Kadena Air Base in Okinawa, Japan. The U.S. Air Force's mighty Raptor was felled by the International Date Line (IDL).
When the group of Raptors crossed over the IDL, multiple computer systems crashed on the planes. Everything from fuel subsystems, to navigation and partial communications were completely taken offline. Numerous attempts were made to "reboot" the systems to no avail.
Luckily for the Raptors, there were no weather issues that day so visibility was not a problem. Also, the Raptors had their refueling tankers as guide dogs to "carry" them back to safety. "They needed help. Had they gotten separated from their tankers or had the weather been bad, they had no attitude reference. They had no communications or navigation," said Retired Air Force Major General Don Shepperd. "They would have turned around and probably could have found the Hawaiian Islands. But if the weather had been bad on approach, there could have been real trouble.”
...
-
-
-
-
-
Monday 20th February 2012 10:20 GMT Chris Miller
Unless you're running an atomic clock, UTC = GMT. The name was changed to appease our French amis who were sulking because the world runs on London local time and meridians and not Paris (as they wanted in 1884).
Oh, and Jake, DST may not matter to dirt farmers, but modern society is a tad more complex than that. Sure every school, factory and shop could decide when they were going to adjust opening and closing times to fit in with local daylight, but do you really think that would be easier or less confusing than having a government mandated day for everyone to do it? Now, if only we could convince good ol' Uncle Sam to follow the same dates as the rest of the world - we've done it for autumn (sorry, fall), just spring to sort out ...
-
Monday 20th February 2012 12:25 GMT vagabondo
@Chris Miller
GMT is the name of the time-zone used in the UK. Time-zones are designated by governments as an administrative convenience. GMT was also used as the name of a time standard prior to 1928, when the time standard's name was changed to UT1. The time within the GMT zone is set at UT1. Computers, satellites, NTP etc. use UTC. UTC has been established since 1961 and is now maintained (by means of leap seconds) to approximate UT1 (and hence GMT).
-
Tuesday 21st February 2012 08:49 GMT cloudberry
@vagabondo
"GMT was also used as the name of a time standard prior to 1928, when the time standard's name was changed to UT1. The time within the GMT zone is set at UT1."
Not exactly. "GMT" is nowadays synonymous with "UTC+0". UT1 is the mean solar time on the Prime Meridian at Greenwich, which is not used as the civil time in Britain (or anywhere else) anymore.
-
-
Tuesday 21st February 2012 08:46 GMT cloudberry
@Chris Miller
"Unless you're running an atomic clock, UTC = GMT. The name was changed to appease our French amis who were sulking because the world runs on London local time and meridians and not Paris (as they wanted in 1884)."
You know, not everything in the world is about the French vs. the British, and Britons blaming things on "the sulking French" or whatnot is getting just bloody tiresome. (I'm neither French or British, in case that matters.)
http://en.wikipedia.org/wiki/Coordinated_Universal_Time tells us:
'The official notation for Coordinated Universal Time is UTC. This notation arose from a desire by the International Telecommunication Union and the International Astronomical Union to use the same notation in all languages. English speakers originally proposed "CUT" (for "coordinated universal time"), while French speakers proposed "TUC" (for "temps universel coordonné"). The compromise that emerged was UTC, which conforms to the pattern for the notations of the variants of Universal Time (UT0, UT1, UT2, UT1R etc.).'
...
'UTC was officially initiated at the start of 1961 (but the name Coordinated Universal Time was not adopted by the International Astronomical Union until 1967).'
-
-
-
-
-
Monday 20th February 2012 15:42 GMT JDX
Re: And that is why...
>>The safety-critical systems I worked with ran everything on GMT. The local time was simply translated to and from GMT when required.
There really is no excuse for this sort of thing.
I think you're oversimplifying. Converting all times to UTC is not a universal fix for DST issues. The moment you have an event which spans a DST cross-over, or you are working with a date in the future after the next changeover, problems start to creep back in.
When countries move their DST changeover date (USA did recently), even more difficult.
-
Monday 20th February 2012 20:37 GMT Vic
Re: Re: And that is why...
> The moment you have an event which spans a DST cross-over,
>or you are working with a date in the future after the next changeover,
> problems start to creep back in
No.
UTC is monotonic. If one event happens after another, the UTC date for that event is later than the previous event.
So you're never dealing with an event "in the future".
Converting from those UTC dates back to local times might give slightly "odd" results on page views, but you only get odd calculation results if you're trying to calculate using those local times. Calculating with UTC gives you a nice monotonic variable that doesn't cause problems.
Vic.
-
Monday 20th February 2012 20:50 GMT JDX
Re: Re: Re: And that is why...
>>So you're never dealing with an event "in the future".
I don't care what time system you use, next Tuesday is in the future. I'm not talking about issues of "is it 1am or is it 1am again". I'm talking about a person creating an event that runs from 1500 today until 1500 in 4 months time... we have a problem with the human's understanding what that means, which can lead to misunderstood behaviour... the event lasts 1 hour more less than the user expects and this has some weird side effect nobody thought off.
So it's not a direct problem of tracking times, but indirect problems where requirements miss edge cases, or users don't understand the system... ultimately user error but the problems still remain.
-
Tuesday 21st February 2012 02:14 GMT Vic
Re: Re: Re: Re: And that is why...
> event that runs from 1500 today until 1500 in 4 months time
This is the usual GIGO situation; if a user can't think through what he means, errors will occur in any system that allows that user any form of control over anything.
If the user specifies that something ends at 1500 localtime on a particular day, then that is what happens. If he happened to mean that the task lasts for a certain number of hours, there's no amount of defensive programming or farting around with timezones that will prevent him saying one thing and meaning another.
> ultimately user error but the problems still remain.
Them's the breaks. You either trust humans to get their act together, or you don't. Does this user want the job to end at 3pm, or does he want it to last (n*24) hours? Whichever design decision you take initially, some user will get it wrong. This isn't something for which code design decisions should usually be blamed...
Vic.
-
-
-
-
-
Monday 20th February 2012 09:06 GMT Jacqui
IT spec - phone spec
For many years switches have avoided DST for simplicity and prior confusion, but smaller VOIP and office PBX's have synced to local ntp servers and applied DST - sometimes incorrectly (many US products) apply one or other US zones by default.
The problem is more complex as call centres (and lets say the Met) use call data records (CDR) but assume incorrect DST offsets and end up an hour or so out.
I suspect this is another .gov.uk spec written by highly paid but technically unskilled consultants or the "injuns" blindly followed the spec.
Pay peanuts...
-
Monday 20th February 2012 10:01 GMT James 100
What will it take to consign this bonkers anachronism to the dustbin of history, actual deaths?
It's hard to see which is more stupid here: the 999 call handling system losing dozens of calls because of a very dumb bug, or the government ordering us all to shuffle the numbers around the clock twice a year as if labelling sunlight hours as being 9am to 3pm up here in the frozen north instead of 8am to 2pm is an improvement in anything.
"Dear politician: if you want to 'save daylight', please use a solar panel, rechargeable battery and torch. F**k off and quit tampering with my clock, even a politician should be able to grasp that it doesn't actually control daylight!"
-
Monday 20th February 2012 10:22 GMT Anonymous Coward
Which is why......
when I was running critical 9s systems they were always set to UTC0 all year round, much better from an evidentiary point of view too as there is never two 0100s or 0200s. An offset to local time can always be declared later.
Why not just have one time worldwide UTC0 and then work around whatever hours happen to be daylight where you are? After all it's only a number. It's complete bollocks to say that we are gaining or loosing daylight with a clock change, the amount of daylight / night is *exactly* the damn same. Would make scheduling worldwide conference calls a damn site easier too!
-
Tuesday 21st February 2012 08:33 GMT cloudberry
Re: Which is why......
"Why not just have one time worldwide UTC0 and then work around whatever hours happen to be daylight where you are?"
We do; it's called UTC, which is the planet's official time.
For instance, in civil aviation, times are always expressed in UTC, in order to prevent misunderstandings concerning the timezone being used.
-
-
-
-
-
Monday 20th February 2012 13:07 GMT Vic
Re: Re: Re: bad programming
> it would have to include an accurate local time as well as running to UTC
Nonsense.
If you know UTC and you know which timezone you are in, you can derive localtime precisely.
> otherwise you could have a situation of a crime being reported before it happens.
No you couldn't.
Crime happens at $time. Report happens at $time+$delay. As they are within the same reference, $delay can never be negative.
This is pretty basic stuff...
Vic.
-
Monday 20th February 2012 15:40 GMT nsld
@ Vic
"> it would have to include an accurate local time as well as running to UTC
Nonsense.
If you know UTC and you know which timezone you are in, you can derive localtime precisely."
I quoted your first part as it includes the bit you claim is nonsense and then you proceed to say exactly the same thing.
UTC provides the baseline, local time is derived from that and recorded accordingly to allow for time changes.
For evidential purposes you cannot derive a time after the fact it needs to be logged at the time of the event so a call record in summer time would show UTC at X and local at X + 1
and thats why, with the current approach they have if they lose an hour and the time of the call is not accurately recorded then a suspect could argue/show they where not at the scene at the time of the call should the log be produced in evidence.
-
Monday 20th February 2012 20:44 GMT Vic
Re: @ Vic
> I quoted your first part as it includes the bit you claim is nonsense
No it doesn't. It says the exact opposite.
You claimed that it is necessary to record UTC *and* localtime. I claim that it is only necessary to record UTC because localtime is trivially derived from it. The reverse is not true.
> UTC provides the baseline
UTC provides the *time*. Nothing to do with baselines.
> local time is derived from that and recorded accordingly to allow for time changes.
No. Localtime is derived from UTC when needed. Localtime is never stored - never. It is always derived (for display purposes - never for calculation).
> For evidential purposes you cannot derive a time after the fact
Of course you can.
Storing UTC tells you when the event happens. From there, it is a trivial amount of processing to work out what time was on someone's wristwatch at that time.
> a call record in summer time would show UTC at X and local at X + 1
Irrelevant. The local time just doesn't matter.
If you have event 1 happening at local time X, then event 2 happening one hour later, just after the end of DST, that also happens at local time X.
But if you record in UTC, event 1 happens at time Y, and event 2 happens at time Y+1 hour. The conversion to localtime is trivial.
> a suspect could argue/show they where not at the scene at the time of the call
You don't appear to understand that UTC does not have aliased timepoints in the way local times do...
Vic.
-
-
-
-
-
-
Monday 20th February 2012 13:48 GMT Anonymous Coward
TZ, oh what fun
TZ changes and that included the summer/winter versions called daylight saving are a great source of fun in IT. It's also remarkable that how something so simple, and very well understood; Still manages to casue newer and more creative problems. Indeed it also appears the faster computers go the more varied the problems from this appear.
Sadly we still force computers to think like humans and humans to think like computers in alot of area's and that casues issues.
Indeed why we deemed that computers had to log to a time we operate on instead of using a fixed TZ every second and day of the year and then just map that onto the human needed version is one area alot of people don't see as needed and also the same people who don't see the problems clearly. Alot of people saying yeah lets abolish siummertime etc and all will be well. Well in the face of it that is true it still has the mentality that one shoe fits all. This ignores the fact that we have leap-seconds and leap-years and other tweaks that will impose on your computer clock if you let them. If the computer internaly and all the programs worked on its own internal birth time synced to UTC and any time related stuff a human needed to look at got translated to what the time would be catering for all the TZ and summertime changes and at the same time not ever having to change the actual time, then everything would be alot smoother.
This all said alot of people just like to change the time on computers, just ot piss of the accountant mentality people as to them it's like using tipex on the accountancy book.
Me personaly I'd so just hack the kernel to detect any time changes and have the OS bleat at the user, "I'm sorry Dave I can't alow you to do that, it would violate the laws of relativity for my data".
-
Monday 20th February 2012 15:37 GMT Tim Elphick
Summer time please
Can i just say, in case anybody important is reading (no offence) that if we're allowed to keep one time can it be summer time? I spend my mornings getting ready for work, but more light in the winter evenings would be nice. I'm fairly confident I haven't got that backwards, have I?
I am aware that time needs other adjustments to keep up with daylight. I don't know if the regular changes we have might make it easier to add in these changes.
-
Monday 20th February 2012 21:28 GMT Anonymous Coward
Re: Summer time please
Fair enough, you and quite a few others probably.
But rather than faff about with the clocks in a way that midday is no longer midday, why not ask your employers to adjust your working hours?
I know, it's never going to happen because employers on the whole are a bunch of clueless stiffs, but...
-
This topic is closed for new posts.
Biting the hand that feeds IT
