Cashpoints?
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)
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 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
