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 Service …
Do their devs also run any cashpoint software? I'm thinking I might pull a few hundred quid at 1.30am and then the same again...at 1.30am ;O)
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!"
Russia abolished these stupid twice-yearly clock changes
We can, too. Write to your MP!
Re: Russia abolished these stupid twice-yearly clock changes
"Write to your MP!"
Is that your Minor Putin, then?
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!
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.
System needs two time stamps, UTC and then local time. UTC remains unchanged, local time follows the local time.
That way the system doesnt dump an hours calls on a time change becuase its driven from the UTC variable
Re: bad programming
All real (i.e. not Toytown) systems only use UTC timestamps. Local time is applied as a GUI parameter.
Re: Re: bad programming
Problem with the 999 system is it provides evidential material for criminal prosecutions so it would have to include an accurate local time as well as running to UTC otherwise you could have a situation of a crime being reported before it happens.
Re: Re: Re: bad programming
> it would have to include an accurate local time as well as running to UTC
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...
Re: Re: Re: bad programming
The problem with local time is that it is not monotonic. You can always derive Local time from GMT, but there are cases when a given local time can refer to two moments one hour apart.
"> it would have to include an accurate local time as well as running to UTC
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.
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...
Re: Re: @ Vic
Vic - quite agree.
nsld - bollocks.
If the court can't handle the concept of UTC (or GMT) then it is not competant to try the case.
Systems Administration 101
Another .gov.uk IT cockup. Surely there's somebody there who knows that you run critical, timing dependent systems on GMT, FGS?
Re: Systems Administration 101
Nowhere in the article does it actually say the software was actually running on local time, only that the changeover caused a problem. What their servers were doing is not mentioned, unless anyone has a link to a more in-depth analysis they can quote from?
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".
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.
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...
Try being south of the equator
and finding that the shitty DST code in your least favourite operating system makes some fairly boneheaded assumptions about being in Redmond.
Having clocks go BACKWARDS in spring tends to break things even worse than not moving at all.
The mind boggles ... Most of you lot REALLY don't get the complexity of "human time", do you?
See my post:
With a nod to Heironymous Coward's:
And my reply: