Re: Time-of-Day reference

How badly wrong was the phone?

In theory from the network, which should be the legal and correct time for the country. But not all providers transmit it correctly. I have seen some that do not send the time at all or it is totally incorrect.

I don't know how GPS time is integrated with that (in the phone). Then there is also NTP.

Notice that GPS and NTP transmits UTC time, which would have to be corrected for the estimated time zone, which is not necessarily the legal time of the country.

The end result is that in most places the phone has a very correct time.

It does look like a software bug or random memory corruption. An incorrect time zone offset from UTC would certainly give the observed effect which would then persist until the phone rebooted. Some places have offsets of 30 minutes and I think there may be somewhere with a 15 minute offset from an integer number of hours. I haven't come across an intentional offset of around 10 minutes. John

I have seen errors of hours and minutes, so not a time zone offset; simply that the telco did not set up the clock at all. Some telcos did not publish the time, which is better than a wrong one, kind of.

I worked for some telcos, on fixed line stuff. On the 5ess there was a high precision time module that the telco I was working for did not buy, as it was hugely expensive (think of a quartz based clock inside a temperature controlled oven, and more). On another, we set the clock manually on a terminal, and someone was tasked with having a look monthly. The time was used internally for billing and reporting. The switch did not have networking capabilities, as in Internet nor LAN, so it was impossible to set the time via NTP.

And that attitude I guess was similar on the mobile phone network providers, too. I suspect that Google knew this and took action eventually, so that now most phones display correct time.

But I remember years ago that I had an app that would set up the clock using NTP protocols, till some update prohibited userland from adjusting the clock.

Normally 1Hz. Some receivers can be set to update to 10Hz. Various NMEA-0183 sentences have different minimum output rates:

The minimum NMEA sentence requirements matter. The most important is that the GPGGA and GPRMC message output once per second. GPGGA - must be once/second GPRMC - must be once/second GPZDA - must be once/second NMEATime will use this sentence for time. If not available, then NMEATIme will use GGA & RMC for time. GPGSA - every two seconds GPGSV - every two seconds

Maker and model? I have a junk box full of older and prototype GPS receivers where the manufactory did not see fit to update the firmware to the latest changes. Strangely, the symptoms vary from incorrect time, as in the photo example I provided, to playing dead. Leap seconds were added in June 1972. Updates on older units arrived later.

Once again. There's no polling and no requesting time. The NMEA-0183 data is one way coming from the receiver and going to the connected device (which includes a human readable clock display). Some implementation use a serial port with the reverse path pin missing from the serial port. Others use the return path on the serial port for programming the GPS receiver.

If you have a GPS receiver that belches NMEA-0183, you can see what's happening with some PC software:

Oops. I goofed. The minimums mentioned above are the minimums for the PC software to operate properly. However, the times do represent typical values.

Also, output errors could also have been caused by the week rollover error. However, the one's I've seen usually produce insane dates and times:

"GPS week number rollover"

"GPS Week Number Rollover April 6, 2019"

Your Old GPS Receiver Will Never Work Again... Magellan 2000