Posted
by
timothy
on Wednesday May 23, 2012 @11:21AM
from the why-the-economist-rocks dept.

An anonymous reader writes "A man with one clock knows what time it is, goes the old saw, a man with two is never sure. Imagine the confusion, then, experienced by a doctor with dozens. Julian Goldman is an anaesthetist at Massachusetts General Hospital in Boston. After beginning to administer blood-thinning medication during an urgent neurological procedure in 2005, Mr Goldman noticed that the EMR had recorded him checking the level of clotting 22 minutes earlier. As a result, four hospitals in the northeast had their medical devices checked, and found that on average they were off by 24 minutes. The easy solution that devices could have used since 1985? NTP."

First, they will use Windows Active Directory for NTP because someone will say "it's authoritative for the whole network". And their clocks will be off.

Then they will run into config hell, and blaming that for clocks being off - they will load balance the domain controllers. Which is precisely what you're not supposed to do with NTP. And their clocks will be off.

Then, some small but relevant IT subgroup will secede, claiming that they need "real" NTP. "Network Security" folks are typical suspects here. So their clocks won't match the rest of the gear (which is still off, remember?)

If you have poor enough technology discipline that your clocks are 24 minutes off already, you're probably screwed.

First, they will use Windows Active Directory for NTP because someone will say "it's authoritative for the whole network". And their clocks will be off.

Then they will run into config hell, and blaming that for clocks being off - they will load balance the domain controllers. Which is precisely what you're not supposed to do with NTP. And their clocks will be off.

Active Directory time synchronization works properly if you have a competent sysadmin and set it up correctly. If you don't have competent sysadmin it doesn't matter the technology or vendor you are using, you will get it wrong.

Active Directory domain controllers don't need external load balancing, they automatically distribute work out of the box. When configured correctly they also set up a proper NTP time hierarchy.

From my experience in hospital environments, radio reception is often VERY poor. You've got lots of metal in their construction that tends to block signals. Doubtful you'll have any luck receiving a time signal via GPS unless you plan on running antennas all the way up to the roof of the building.

As I posted already, NTP is a perfectly good way to solve this problem. You simply have ONE system designed to be your time server, which synchronizes over the Internet via NTP, and then all the firewalled off dev

Better yet: this is not an application that requires microsecond precision--within a minute or two is fine, particularly as long as all the clocks agree with each other. Completely private network with a master NTP server that is updated by hand every week or so should work fine.

I looked into this last year for a project and it is actually pretty hard to get an accurate time signal cheaply inside a building. NTP works but needs ethernet and TCP/IP, and either a cable or wifi (which means WPA authentication etc.)

GPS is very accurate but tends not to work well indoors, especially in rooms with no windows like most operating theatres. Around the world there are various low frequency time signals (DCF77, JYY, MSF etc.) but like GPS reception can be a problem. I live in the UK and DCF77

So... don't. NTP works just fine on a private network. And you don't even need a proper time source, either. As long as everything ticks within a narrow boundary of time, it doesn't really matter if the master NTP server clock is off. If it's stable, the offset between it and the real time would be well known.

NTP's just a way to distribute the time. It doesn't have to be used to distribute exact time. As long as everything's ticking to the same clock, things

That depends entirely on the purpose of the medical device. "Medical devices" covers a lot of products that serve a lot of different purposes. For some devices internet access would be pointless, for others internet access would be dangerous, and for still others internet access makes perfect sense. It depends entirely on what you are doing with it and what the risks are. There is nothing inherently wrong with hooking up a medical device to the internet, provided that the risks of doing so have been ade

Not a problem, as almost all GPS time sync devices are mounted on the roof. (Hint cement and rebar that hospitals are made of is bad for satellite reception)

I'm guessing you dont know much about network time sync devices and how they work. And the MRI machine has a funny cable that runs in to the control room that has the magical ability to bypass a faraday cage.

Consider that they need not even setup a dedicated server, most core networking gear can provide authenticated NTP by itself with a battery backed up RTC with enough accuracy to keep within a few seconds a year. Consider that some of these devices already have a network connection to talk back to the EMR software anyways.

Setting up a whole new standard is foolhardy, setting up a RF based standard in a hospital setting is looking for trouble. Adding a procedure that needs to be done is just adding cost. I

Now there's another reason for the enemy to take out the satellites, or jam GPS.

No, the server would go into free-run mode if it cannot receive a signal, and all of the clocks would be the same, just with a little bit of drift. And even if the servers went down, in the worst case, the devices would do the same thing, which means even in the worst case, you would be no worse off than you are now, and realistically, because NTP provides drift compensation statistics, they would probably drift far less than t

Why does clock drift happen? It doesn't need to happen. It can totally be avoided. It only happens because the equipment manufacturers design inaccurate clocks to save money. My quartz LCD watch from 1985 was accurate to within 1 second per year. That would WAY outlast the usefulness of the medical device. There should be no way in the world that device was off by 24 minutes.

Right now, I'm dealing with the same problem in my brand new car. It has a fancy on-board computer with a screen that tells me gas mileage, service info, mp3 and radio interface, etc.... The clock is ridiculously fast (gains 3 minutes a week). My new $20,000 car should have a clock in it at LEAST as accurate as the watch I can get from a happy meal.

NTP have the problem of discontinuing his UTC timestamp while a leap second occur and NTP do not broadcast the actual UTC-TAI offset (historically because he broadcast UTC directly but this is now more a problem that an advantage). GPS and PTP broadcast (something very closely related to) TAI and a UTC-TAI offset, witch is the right thing to provides the precise actual time without discontinuity.

But all of them, NTP, GPS and PTP, have the problem of not broadcasting the historical leap second table, making the client of those protocols alone unable to safely compute a precise date in the past. I hope next NTP protocol will broadcast TAI, and that NTP, GPS and PTP will be able one day to broadcast the leap second table. I am certain that there is still some reserved bits somewhere in those protocol to make that working.

Look if the options are 24 minutes of random error or say 24 seconds of consistently biased error in all the devices in the hospital, I'll take the consistent bias any day. The point of all of this is so that a nurse walking into the room and seeing a blue lipped coma patient can determine things like how long has it been since the monitor whose leads fell off last recorded an accurate O2 saturation.

We are talking about medical equipment that would have to be certified by the FDA. That would mean that every GPS receiver and every implementation of local NTP would have to go through a rigorous and costly certification process. The following issues would have to be certified;1. Is the device accurate.2. How does the device interact with the software.3. How does the device interact with every device receiving data. This is the hard part.

Secondly, is it even necessary? The issue seems to be that there is an offset between the clock on the equipment and actual time. How about at the beginning of the operation the doctor writes down all the times as stated on the medical equipment. If necessary these offsets can be applied later to normalize the times. This reminds me of the time when the US spent tens of thousands of dollars to build a pen that would work in zero gravity(it was pressurized with gas). When a cosmonaut was asked how they coped he said "In Russia we use pencil". Sometimes high tech just complicates the issue.

This is often a case of poor administration, perhaps more frequently than poor design.

For example, I was recently tasked with reviewing the performance of several hospitals in the diagnosis and treatment of stroke. Under national guidelines (UK) a patient with suspected stroke must have had a CT scan within 30 minutes of arrival at hospital, with blood-thinning treatment administered within 60 minutes (if appropriate).

The problem was that the times on the CT scanners were discrepant by +/- 45 minutes from true time - so the images were tagged with the incorrect time. Further, the CT viewing workstations had times up to 2 hours discrepant. The CT scanners were Windows or Gentoo depending on the manufacturer's preference. Similarly, the CT workstations were windows, and were all bound to the hospital domain.

The time discrepancies made my assessment very difficult - and I had to correct for each individual scanner, and assume that the clocks hadn't drifted over the 6 month period of the audit.

I also found several safety issues because of this - e.g. if it was 1am, and a patient had a CT scan, some workstations would be 2 hours slow, so would read 11 pm on the previous day. These workstations would refuse to load the CT scan because the files were filtered by "WHERE [StudyTime] NOW".

I raised a support issue with the workstation vendor who simply said "These are windows workstations. You should ensure that they are appropriately bound to your domain, and configured to sync with your time server or domain controller". So I called IT to configure this, "No way. These are medical devices, we can't change the configuration - and anyway, what will happen if the clock is fast, and the sync pushes the clock back, so that there are 2 occurrences on the same time. That would cause chaos. Even if the manufacturer supports it, there's no way we'll set it up". Of course, their concern doesn't actually exist, because most time sync algorithms (even on Windows) are clever enough to avoid "double time".

There was similar obstruction with the CT scanners. The vendors simply said - we support and encourage synchronisation with a time server. IT or the radiology administrators simply stonewalled the ideas. They refused even to correct the clocks on teh scanners - so the clocks are still wrong to this day (even more so, due to accumulated drift).

Of course, even if the time can be set right - there is disagreement as to how daylight-saving is managed. Some equipment, esp. older embedded kit isn't daylight-saving aware. Do you set it to Summer time or winter time? In most hospitals I've been in, it's been an inconsistent mixture - often with lots of clock drift added, so you can't actually be sure.

When I had a hospital gig, we knew back in 1995 that time would need to be syncronized amongst all the servers etc. We ran a local time server synched to a Tier 1 NTP server which was fortuitiously about 180 miles away. It has since gone to restricted access, but it's nailed to the USNO, and is still a Stratum One server. I bet they still use it as reference.

But even in 1995, NetWare servers were well behaved and accept NTP, and we set workstation time on login. As other servers came on, we went through the inevitable 'my server is more accurate' and blew them off until the Sun server showed up,and they refused to use our NTP. Fine. Took two weeks to resolve a 300ms difference, and then I watched as they re-fixed the error and synched with the NTP server they initially refused to use. In fariness, it was not SUN engineers involved, but they were arrogant enough to qualify.

Time is important to networks.

We did not, however, have any way to manage time on 'devices', such as infusion appliances etc. I do NOT think of an EMR as a 'medical device'. Nor do I think of the EMR sytem that way either. But if time isn't being synched on your network, you got some other problems, I suspect, that are not making your work easier or efficient as a network admin.

Once upon a time not so long ago, I wrote EMR software. You have to realize that there's no standard for medical devices and their information reporting; each manufacturer, sometimes each device model, is different. Some of them are quite old, or at least use interfaces that are quite old and haven't been updated in a long time (for compatibility reasons, of course.) Most still use 9-pin serial cables (USB developed: 1994.)

I would never trust the reported time from any device. Use the time that the recording system receives the data as the time of record (and poll data often.) Who cares what time the device thinks it is, along as it tells you the current data "now" and YOU know when "now" is?

Easy, get a GPS receiver and use its time. The point is that the times all need to be the *same* (so things that happen at the same time are recorded as such); accuracy is secondary. Even if every week or two some guy goes and fixes the clock on the server, that should be acceptable.

Even if your interpretation of what devices where effected was true, you would still be a crazy person. The act of receiving GPS signals can not be tracked. To track (for example) an insulin pump, you would need a TRANSMITTER in addition to a receiver.

Is there a difference between leaking [slashdot.org] and transmitting? In practice, I don't think so. Otherwise, how would Britain have been able to use TV detector vans [wikipedia.org] to find households that had not paid the TV licence?

Differences other than the fact that it's much lower power and that it's not transmitting any meaningful information?

Even assuming you had a ridiculously sensitive receiver capable of of listening to GPS receiver's local oscillator you can't differentiate - you can only detect receivers operating at frequency X, and since just about every damn cell phone has GPS these days that's damn near useless for tracking anyone, you've got thousands of blips anywhere with people, and they're not stationary like your T

And how do you go back in time and fix all existing machines, and who pays for it. Even in a new machine this is expensive in an era when everyone's trying to cut costs.

True dat. This is really the big problem. I worked on an ICU monitor system design many years ago (1978 IIRC). The design was cool, total cost of development and productizing back then would have been maybe $100K. But the company discovered that it would cost several $million to get through the various levels of certification and approval to allow hospitals to use it. And once it's developed, even a resistor change would have required the same process again. Based on the projected market, amortizing t

At least then all data logged will have a correct relation and timing of events can be managed if necessary.

If every computer has it's own time then it's impossible to get things straight about when did who do what. And that's critical if something happens and you need to figure out how to correct it so it won't happen again. Of course - it can also be used in the blame game.

And it's not a big problem for a hospital to use NTP if the source used is trustworthy. GPS receiver and/or a trusted NTP server on the net.

At least then all data logged will have a correct relation and timing of events can be managed if necessary.

If every computer has it's own time then it's impossible to get things straight about when did who do what. And that's critical if something happens and you need to figure out how to correct it so it won't happen again. Of course - it can also be used in the blame game.

And it's not a big problem for a hospital to use NTP if the source used is trustworthy. GPS receiver and/or a trusted NTP server on the net.

Don't bother, this guy clearly works in a private healthcare environment, given his complete disregard for *actually* improving the quality of care and instead his direct instinct to preserve his job and/or revenue stream. Anyone who takes more than a casual look at private healthcare can see that there are so so SO many ways to do things better that get completely ignored in favor of doing things the current way, or doing things in a way that makes it easy to dodge a lawsuit.

Your best bet is to go to an "urgent care" facility... the ER has two entrances, the one you walk through and the one ambulances go through... You also get triage based care... the more critical the injury, the faster you are seen. With Urgent Care sites, it's usually first-come first-served.

I've watched accountants transcribe a column of numbers in a spreadsheet into a desktop calculator to sum the column. They can't even use the software they've got! What difference would it make to give them another suite of software they can't use, but which would be vastly cheaper and work just as well (or better)?

I no longer have any patience for this shit. I don't believe a word of that BS about introducing another suite would lead to insurmountable problems for the users. T

Yes it does. As long as all the devices are using the same time server, the problem does not exist. You need consistency not accuracy.

Most hospitals and surgical centers I have dealt with use a master clock system that wirelessly updates time on all devices to about 1-second accuracy. That wouldn't necessarily include things like EKG or blood oxygen meters, hence the issue in the summary-- those devices do not have a central time source typically, although the telemetry systems could add it in to have a common reference.

My sister's a twenty year veteran elementary school teacher. I've heard all about it.

IT challenge is related to gov't regulation how?

Lawyers and doctors still use fax, because faxed signatures are accepted for legal purposes. Both legal and medical professions have draconian requirements for client and patient data protection. Just read any story related to medicine or law and note their paranoia about connecting *anything* to the Internet. If it's not regulatorily required, it's fear of being sued.

And please do tell how this unspoken rational outweighs simply being cash strapped and crisis focused?

In many cases, consistency between two clocks and moving at the correct rate is FAR more important than absolute correctness. For example, it hardly matters if the hospital's clocks all think it's Feb 3rd 213AD so long as you know that the patient's last dose was 3 hours ago. If the clock in the patient's room thinks it's an hour later than the one in the recovery room, that could matter.

It just makes all the clocks on the hospital go wrong when it starts to move to wrong times on the NTP server.

Including the clock in the hall. Everything but the doctor's watch. Therefore, for the most part, all of them would be self-consistent. The reason this was a problem is that the doctor nearly performed a medical procedure twice because one person was using one clock as a baseline and another person was using a different clock. If all the clocks use the same baseline, they will all be the same.

Having everything on the same clock seems far better than having things on their own out of sync clocks.

Sure that one device says it did something at 1:15pm doesn't mean it actually did, but if another device says the current time is 2:15pm then it was an hour ago since they are both out of sync with the actual time by the same factor.

And of course whenever there's some sort of external check (a nurse looking at their watch) then to fix the device all the devices get fixed rather than just that one. So your

Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.

NTP does not require access to public networks. Private time servers, usually GPS sourced via rooftop antennas, are very common.

I am just playing with one said GPS unit. US$50, plus USB/Serial cable, plus conversion chips. 4h work, less than US$80 in hardware. There are ready made units for around $400, with a rubidium standard if the GPS is not available.

You don't need to connect to an outside server. You can easily run your own time source (GPS is really easy these days), or have the devices talk to a single internal server which then securely contacts outward. If they're off, at least they're all on the same time. It's really dangerous if everything is reporting different incorrect times.

Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.

Sometimes the ideas non-thinking geeks come up truly scare me.

No one said the NTP server had to be external. NTP is just a method to keep a bunch of clocks synchronized to an arbitrary master.

Sometimes the stupidity of non-technical and non-thoughtful people scare me.

You could do an implementation of NTP on a closed network, with a local time source(compared to the rest of a hospital, an OK atomic clock doesn't cost that much, and a GPS timebase could be lost in a rounding error) with devices flagging anomalies in the NTP source and falling back on local quartz oscillators if needed.

It'd be more expensive than just having IT bring a patch cable; but there isn't anything about "NTP" that requires putting gramps' pacemaker on the internet...

For the original poster, the local atomic clock would indeed be a real atomic clock, so your NTP master clock drift ought to be minimal even if you only sync nightly. Of course, it's far more likely that a couple of cheap GPS receivers would be used in practice. Other servers and desktop machines would sync time using NTP over the existing internal network.

The "atomic" clocks that merely sync to the NIST radio timebase are toys; but you can get perfectly real atomic clocks for (relatively) small money. I haven't been comparison shopping or anything recently; but the 5071a provided a handy rack-mount caesium frequency reference for ~$50,000 back when Agilent sold them. Compared to the rest of the cost of getting an hospital-wide EMR system and a whole bunch of life critical gear from several dozen vendors chatting amicably, the timebase will count as a pleasan

The issue isn't accuracy. As you mentioned, even being off by a minute or two is rarely important. The problem is that all the little medical gizmos are not and will not be on any sort of network. The security ramifications of putting every last IV pump on the hospital network are simply too great to deal with, at least at present. Nobody is going to set up yet another network for time signals.

For larger, already networked machines - at least modern ones already are talking to a time server. Just looked at

NTP is just a protocol that you can implement. There are solutions that you can install internally that don't require internet access. Just stand up your own internal NTP server and have your own internal official time (possibly synced to something more authoritative). I agree with your sentiment about keeping sensitive medical equipment disconnected from the internet but with hospitals becoming more and more interconnected and not having their own physical infrastructure to do so, the internet looks like it's probably the best option. Yes, there are way to protect your traffic and all that but I must be pedantic and point out that NTP does not mean you must use the common servers available on the internet.

If you have multiple NTP servers, then your suggestion of "haywire" is moot. (I love your haywire suggestion by the way, that it's guaranteed to fail in such a way to cause everything to drift.... Oooohhh bogeyman!) Also, buy a dedicated device. I have GPS based NTP servers which now have an uptime of the last time I moved them (6 months). Before that, the uptime was from when they were comissioned (4 - 5 years ago). We measure their drift in nanoseconds.

Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server?

NTP works on private networks too. Set up your own internal NTP service.

Because running it yourself does no good, it can just fuck up all the devices in the hospital.

I'm not sure what you're trying to say here. But it strikes me that having a common time seems to have more upside than down (at least for devices that need to have an internal time clock).

I don't get why people (like the parent poster) are blowing this up, out of proportion?

You don't have to expose all of the hospital devices/systems to the Internet, just to ensure they all have the same, accurate clock time!!

All you need is ONE device permitted to access the proper port for NTP protocol through a firewall, to set its own clock as the master, and then have it redistribute the date/time info to the remaining devices on the hospital's LAN!

And yet device makers create equipment that requires their time to be set...

I can't help but wonder why they don't use a different report style. If you want to look at the log to see when the last event occurred, why not report in elapsed time? Like:20 min ago: 10cc of supermed dispensed40 min ago: 5cc of supermed dispensed60 min ago: unit reset

I thought of another good solution - when the electronic reporting system polls a device, it should ask the device what time the device thinks it is, and then adjust the report from the device accordingly.

Older devices without either the option to report in elapsed time or the ability to tell you the current time would be a problem. You'd have to either ignore the timestamps until someone manually verifies the time - which would be a joke since everyone would just click "Verify" without actually looking at

As I understand it (which may be incorrect) a lot of units that are timed devices, just reference themselves. If you set an IV pump to dispense #mg every 5 minutes, it doesn't check the time, it only waits for that interval to pass. You don't want every device to be network attached. If you're on 5mg morphine once every 5 minutes (60mg/hr), it would be rather bad if some network based exploit changed the reported dispensed fluid to saline, and changed the rate to 10mg/min (600mg/hr). It

Mod the parent up. I used to program IV pumps and this is exactly what was done. You never used the wall clock or "display time" for dosages. It was always based on a rate and the internal clock always kept track of time differentials, not the actual time.

Can't speak for all medical equipment, but I worked on a major IV pump and it used time in exactly this way. The dosages were rate or interval based and the pump strictly used the internal clock to calculate elapsed time. There was a "clock" on the display but it was only used for display purposes, you could set it for 1:00 am Mar 3, 1983 and it would still work correctly.

You're absolutely correct. It seems intuitive to us that all devices should be networked. An in-house NTP server would satisfy this time sync need. As we've already seen with many other things, even a machine with no network access can be compromised by another that does.

I happened to be in a doctors office (out patient surgical suite) today. Everything had a sign-off sheet with it, where someone would check everything daily. Even the portable O2 tanks were checked to ma

The sysadmins try, but fail. Most hospital networks and devices ARE connected to the internet in some way. Doctors want their access from the various desktop machines, of course, but many of the diagnostic machines offer things like "click this button to email the ultrasound pictures". So they do.

I was appalled to learn this a few years ago from a hospital sysadmin here on/. The thing he pointed out is that Doctors are Gods. If they say "This thing can email pictures? Well yeah, hook it up!" then the sysadmin has zero choice. Holes get punched in firewalls that should never have been punched, and the gear gets hooked up.

And because medical devices are certified only to work with a particular operating system at a particular patch level, they don't get upgraded unless the vendor comes out with a new certified patched OS. That means the ultrasound machine sitting on that cart might still be running Windows XP SP 1. It's crazy.

NTP would actually be the least of their worries. That's something they could more easily house internally.

Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.

Sometimes the ideas non-thinking geeks come up truly scare me.

So the GPS synced clocks used to generate microsecond-accurate timing distributed via NTP for utility billing, high speed trading, and a million other mission critical (read: *beyond* life critical) things aren't good enough for your EMR tablet to update on once a day? Sure thing. Keep hiding under that table.

Who is talking about connecting to an outside server : just have one ntp server running in the hospital, and all devices synchronize to that.Then at least all the devices in the hospital will be synchronized, which I guess is the most important.

Holy hell, what about no? There's a huge reason why hospitals try to keep off networks, especially public ones. Do you really want to connect all the timing devices in a hospital to an outside public server? Because running it yourself does no good, it can just fuck up all the devices in the hospital.

Sometimes the ideas non-thinking geeks come up truly scare me.

So the problem posited by TFA is that device clocks with the wrong times lead to improper treatment. The solution offered is a central time server utilzing the NTP protocol. You've stated that this can just fuck up all the devices in the hospital. (I'm assuming you're getting at the problem of a time server gone bad setting the wrong time for all devices in the hospital.)

So now we weigh the risk of improper treatment due to time differences between devices vs. the risk of an time server failure. To make

You know, as long as the devices in one hospital keep the same time, it doesn't really matter if that time is off by any amount. The important thing is to have all clocks in one building showing the same time, so that the correct elapsed time can be told with just a quick glance. In a medical context, that's usually more important than the current local time.

Nice theory, although if the couple of "atomic" clocks I have around the house are any indicator, it's not a great plan. They only can pick up the radio signal at night (something to do with the ionosphere IIRC), and this in my house with windows in every room. In a hospital? Good luck...

As a result, nearly all Android devices are 15 seconds too fast. Note that iOS compensates for this and shows the correct time.

Then Android devices are not 15 seconds too fast. And GPS isn't either for that matter, you just need to know the offset and you're golden. An accurate clock and a precise, well known offset means you aren't too fast or too slow.

Few people realize this, but Android phones don't keep time correctly [businessinsider.com]. They use GPS satellites for timekeeping, which was last updated in 1982, and since then there have been 15 leap seconds added. As a result, nearly all Android devices are 15 seconds too fast. Note that iOS compensates for this and shows the correct time.

Hmm. [looks at NIST synced PC clock] Hmm. [looks at android phone]

Nope, the two match exactly to 1 second. Unless for some reason my ordinary Android phone (of which over 15 million of this exact variety were sold) qualifies as outside "nearly all" android phones, you are spouting pure nonsense.

1. You don't know how GPS works2. You don't know how network time is set3. You don't know how atomic clocks work.4. You don't know fucking anything about leap seconds and how they're handled by downstream users of GPS clock ticks.

However, I have a phone which allegedly uses network time, and somehow still gets it wrong. Its about five years old, so I am guessing it accesses a time server that is off-line due to a botched implementation, but surely the phone-network time is delivered using a phone protocol and does not depend on NTP?

My post is too long at 55 characters? Is/. using Twitter technology? If 80 column cards were good enough in 1965,. they are good enough now (Lawn:Off)