Message 406 of 482 (786816) 06-27-2016 6:06 PM

Edited by Dr Adequate, : No reason given.

Edited by Dr Adequate, : No reason given.

Message 407 of 482 (794760) 11-24-2016 5:06 PM

OK, having access to precise time, that gives me something to set my digital watch to. That's when I noticed that my phone (Windows Phone 8.1) is about 5 seconds slow. I checked my PCs at work and they were both on the right time within a second. I called WWV (you can do that; follow the chain from Wikipedia to the WWV external site) and our product was right on time. My car has GPS; when I checked its time it was right on time (within a second).

Our cell phones should be getting their time from the cell tower, which in turn should be getting its time from the GPS system. So why would my phone be five seconds off?

ABE:
On a hunch, I just power-cycled my phone. Now it's 10 seconds slow.

Take Two:
Since I'm on my home's WiFi, I turned WiFi off on my phone and power-cycled it again. The idea is to force it to connect to the local cell tower for the time. And it's still 10 seconds slow.

What's going on here?

Message 408 of 482 (794762) 11-24-2016 5:44 PM

Reply to: Message 407 by dwise1 11-24-2016 5:06 PM

I just checked my smart phone, and it seems to be spot with time. But it hasn't always been. It sometimes looks as if a human sets a clock on a whim for the regional center of the carrier, and that is sent out to all cell phones.

Message 410 of 482 (794764) 11-24-2016 6:28 PM

Reply to: Message 409 by dwise1 11-24-2016 6:05 PM

Internally, the cell phone probably uses UTC, with the tower sending an offset from UTC.

Message 411 of 482 (794765) 11-24-2016 7:10 PM

Reply to: Message 410 by nwr 11-24-2016 6:28 PM

GPS satellite signals transmit GPS time (week number and time of week in seconds since start-fo-GPS-time, 1980Jan06 -- only ten bits in the week number, which caused the "1999Aug22 Bug" and led to ad-hoc solutions involving keeping track of which "week-number epoch" we're in) along with the "UTC offset" and associated information about possible upcoming leap-second events. It's up to the receiver to use that data to obtain UTC time to output as well as to generate the 1PPS signal which it outputs within a few nanoseconds of the start of each second.

That 1PPS signal is crucial for the time-division multiplexing of cell-phone signals, because both ends need to know exactly when to start. We have worked with several different GPS receivers over the years. A very few only output GPS time and the UTC offset, requiring you to generate UTC time. Most will output both or either, depending on how you set it up. The newer ones tend to only output UTC time, requiring you to use the UTC offset to generate GPS time if it is needed.

UTC is human-usable time. The whole reason for leap seconds is to keep it synced up with mean solar time (my page on the creationist leap-second claim, DWISE1'S CREATION /...TION PAGE: Earth's Rotation is Slowing, describes how time-keeping works and why we use the length that a second was in 1900). We know that the exact time is known by each cell-tower because they have valid 1PPS signals, without which they could not pass phone traffic between each other. I cannot think of any reason why a cell tower would be designed to add a meaningless offset to UTC.

Now, the discrepancy by where I work is 5 seconds, while the discrepancy at home is 10 seconds. Maybe it's a latency problem, possibly caused by some kind of round-robin polling activity that discovers and pings the phones within the tower's range. That's all I can think of at this point.

Message 413 of 482 (794768) 11-24-2016 9:18 PM

Reply to: Message 411 by dwise1 11-24-2016 7:10 PM

Some people have noted that their Windows phone is at least a few seconds, usually more, off when set to Auto update time.

The best hypothesis seems to be that your phone is setting itself to the time your Carrier sends out. This time is not important for electronic synching. This means local configs may vary and latency issues can be human noticeable.

This is a windows MP8 issue that is a near universal bugbear for Windows phone users. People have tested Windows vs Android in the same location on the same carrier and the Android version is basically spot on, suggesting they are using different sources for the time. This has been an issue with those phones for so long I wonder if doing it in this way is fundamental to the functionality of the OS in some daft way.

Message 415 of 482 (794782) 11-25-2016 12:11 PM

Reply to: Message 414 by Dr Adequate 11-25-2016 11:55 AM

They tend to be standard thread sizes for the diameter of the bolt - particularly in the US where you don't have the metric/imperial problem (unless it's a European model...). So a crude method would be to push a lump of bluetack onto the bolt, then find a bolt that just fits the hole at the store. It'll be crude try it and see stuff. Luckily nuts don't cost anything so you can buy a couple of sizes. Don't forget the washers.

Message 417 of 482 (794785) 11-25-2016 2:32 PM

Reply to: Message 414 by Dr Adequate 11-25-2016 11:55 AM

Or if you know somebody who has a tap-and-die set you could carefully try different dies to see which one fits. As I recall the terminology (I last used one over 40 years ago), a tap is used to cut threads into a hole drilled through metal (you would use a tap on a blank nut) and a die is used to cut threads onto a metal rod in order to turn it into a bolt. Although I worked mainly in carpentry, we did have occasion to re-cut the threads on a stripped bolt, which is why I said "carefully" in the first sentence. A tap-and-die set would be standard equipment in the tool chest of a machinist or of an auto mechanic.

Bolts have standard sizes. They are measured by their diameter and by their thread count (AKA "pitch"). The US Standard has become the Unified Thread Standard (https://en.wikipedia.org/wiki/Unified_Thread_Standard) and uses threads per inch (eg, 32, 24). The terms coarse, fine, and extra fine are also used; I would assume you need fine, which the hardware store should be able to spot looking at your clay impression. And there's also metric. Again, the hardware store would be able to figure that out from your impression.

Message 418 of 482 (794786) 11-25-2016 2:45 PM

Reply to: Message 413 by Modulous 11-24-2016 9:18 PM

It shouldn't be a matter of them using different sources of time. For example, if the Windows phones were set to use an NTP server such as time.windows.com then it would be on-time -- my PC and laptops use that server and are all on-time when freshly synced. Apparently for reasons unknown to us, the phone's clock gets set an appreciably long time after receiving time from the cell tower.

It doesn't cause me any problem. Just a technical puzzle that I, being a geek, needed to solve. Thanks.

Message 419 of 482 (794787) 11-25-2016 3:33 PM

Reply to: Message 412 by nwr 11-24-2016 7:33 PM

Mainly, leap seconds causes problems for computer systems and networks and adds complexity by requiring them to know when a leap-second event will occur and how to handle it. The bottom of that section linked to lists instances where it caused a problem. Our units are designed to handle it both because we are aware of leap-second events (most programmers are not even aware of leap seconds) and because we can query our GPS receivers for when the next one will be (it starts to be included in the GPS signals at least a few months in advance). Most computer systems get their time from NTP servers and I am not aware of any field in an NTP packet that provides that information.

A leap-second event customarily occurs at the end of June or December as needed. It could possibly occur at the and of March or September, but that has never happened. Because of variations in the earth's rotation and other factors, the need for a leap second arises irregularly (eg, they normally occur every 18 months, but there was a seven-year gap between leap-second events from 1998Dec31 to 2005Dec31). The French Time Lords at BIPM (formerly BIH) determine when one is needed and releases a bulletin announcing the upcoming leap-second event. From there, it gets uploaded to the GPS constellation and all GPS receivers are informed.

Systems that don't tie into GPS or whose sysadmins don't read BIPM's bulletin will not know that they will suddenly be hit with an extra second. There are a number of applications where suddenly being off by a second can cause a lot of problems (timestamping and guarding against delays greater than transmission time is a common network security technique). So some argue that syncing up with solar noon (a moving target during the year anyway) is not important enough to cause computer problems. I think that no longer adding leap seconds would result in an error of about one minute after a century; hardly even detectable on your sundial.

Does GMT even exist anymore? The term still gets used, just as locals still call the old WWII Naval Air Station Santa Ana lighter-than-air base the "LTA" even though it was a Marine Corps helicopter station from the 1950's to the 1990's. Or how some will still use the verb "tape" when they take a video. We get too attached to old obsolete terminology.

My understanding is that GMT is no longer maintained. When the term is used, it is intended to refer to UTC (maintained through atomic time) or to UT1 (maintained through astronomical observation -- solar observations were not mentioned). If we stop adding leap seconds to UTC, I can see no reason to continue to add them to UT1.

ABE:
Above, I said:

At the Wikipedia link given above I just now found this:

quote:

---

The NTP packet includes a leap second flag, which informs the user that a leap second is imminent. This, among other things, allows the user to distinguish between a bad measurement that should be ignored and a genuine leap second that should be followed. It has been reported that never, since the monitoring began in 2008 and whether or not a leap second should be inserted, have all NTP servers correctly set their flags on a December 31 or June 30. This is one reason many NTP servers broadcast the wrong time for up to a day after a leap second insertion, and it has been suggested that hackers have exploited this vulnerability.

---

Furthermore, looking up the NTP message format in RFC 2030, we find that the first two bits of the packet are the "Leap Indicator":

quote:

---

Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows:

LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)

---

Though as indicated in Wikipedia, many servers neglect to add that information.

So I stand corrected.

Edited by dwise1, : ABE: correction of my statement regarding NTP support of leap seconds

Edited by dwise1, : Forgot to add my "mea culpa" at the end.

Message 420 of 482 (794788) 11-25-2016 4:38 PM

Reply to: Message 419 by dwise1 11-25-2016 3:33 PM

The historical use of GMT leads to a mildly confusing ambguity today. Here we use Central European Time. In the summer, CET changes by an hour. Through an incredibly sensible piece of international agreement, all of Europe changes their clocks simultaneously. In Portugal, which keeps the same time as the UK, West European Time changes by an hour at exactly the same time as CET does. However, due to the historical legacy of GMT as an international reference time, GMT does not change. Instead the UK switches to BST (British Summer Time). This kind of technicality bothers no one most of the time, except when a client based outside the UK asks me to call them at 15:00 GMT in June, and I'm left baffled if they mean British time or UTC.