From Newsgroup: sci.electronics.design

Do cell phones get their time-of-day references from the
cellular network? GPS (adjusting for leap seconds)? Or both?

In the case of the cellular network, is a timestamp routinely
broadcast? Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On Tue, 26 Aug 2025 19:00:12 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

<https://www.learnbydestroying.com/jeffl/crud/GPS-vs-UTC.jpg>
That was fixed long ago but occasionally haunts me when I play with
old cell phones.

Time standards are a good thing. Every country should have at least
one (or more).

Time Scales
<https://www.ucolick.org/~sla/leapsecs/timescales.html> <https://stjarnhimlen.se/comp/time.html>

What is GPS time?
<https://timetoolsltd.com/gps/what-is-gps-time/>
"GPS time is continuous and is not adjusted to take account of leap
seconds. As leap seconds are introduced over time, GPS time diverges
further and further from UTC. As of March 2019, the GPS time scale is
18 seconds ahead of UTC."

The difference is between GPS time and UTC time is still +18 seconds: <http://leapsecond.com/java/gpsclock.htm>
See table at top of page.

More on GPS time: <https://geomatics.cc/articles/what-is-gps-time-and-how-to-calculate-it-1381>

Do cell phones get their time-of-day references from the
cellular network? GPS (adjusting for leap seconds)? Or both?

In the case of the cellular network, is a timestamp routinely
broadcast? Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

I can't answer all your questions.

The phone has a GPS receiver the acts as an RTC (real time clock). If
there is a low BER (bit error rate) GPS satellite signal, the phone
will use GPS for displaying time. If the satellite signal is absent
or shows a high error rate, it will use the time from the cellular
network.

GPS use NMEA-0183 code to regularly deliver the time. The GPGGA
sentence includes the current UTC time. It's not really broadcasting
because none of the satellites transmit the current time. Instead,
the GPS receiver combines the data from at least 3 satellites and
computes the receiver location. <https://w3.cs.jmu.edu/bernstdh/web/common/help/nmea-sentences.php>
A connected device does NOT poll or query for NMEA-0183 data. The
receiver continuously sends NMEA-0183 data. Connected device filter
the data stream for the specific sentences (such as GPGGA) that it
wants, and uses that to provide time, location, etc.

I don't know what you mean by "timestamp". Are you referring to the standardized formatting of the data such as ISO 8601
("YYYY-MM-DDThh:mm:ssZ")? <https://www.iso.org/iso-8601-date-and-time-format.html>
to make conversion to UTC easier? Otherwise, I haven't seen the term
used with GPS.
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/26/2025 10:03 PM, Jeff Liebermann wrote:

Do cell phones get their time-of-day references from the
cellular network? GPS (adjusting for leap seconds)? Or both?

In the case of the cellular network, is a timestamp routinely
broadcast? Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

I can't answer all your questions.

The phone has a GPS receiver the acts as an RTC (real time clock). If
there is a low BER (bit error rate) GPS satellite signal, the phone
will use GPS for displaying time. If the satellite signal is absent
or shows a high error rate, it will use the time from the cellular
network.

So, the phone (in this mode) is relying on broadcast data.
How often is this updated? 1Hz?

GPS use NMEA-0183 code to regularly deliver the time. The GPGGA
sentence includes the current UTC time. It's not really broadcasting
because none of the satellites transmit the current time. Instead,
the GPS receiver combines the data from at least 3 satellites and
computes the receiver location. <https://w3.cs.jmu.edu/bernstdh/web/common/help/nmea-sentences.php>
A connected device does NOT poll or query for NMEA-0183 data. The
receiver continuously sends NMEA-0183 data. Connected device filter
the data stream for the specific sentences (such as GPGGA) that it
wants, and uses that to provide time, location, etc.

I don't know what you mean by "timestamp". Are you referring to the standardized formatting of the data such as ISO 8601 ("YYYY-MM-DDThh:mm:ssZ")? <https://www.iso.org/iso-8601-date-and-time-format.html>
to make conversion to UTC easier? Otherwise, I haven't seen the term
used with GPS.

I had a phone that was displaying incorrect time. Despite being
configured to "automatically update the time". It continued to
do this for "a long time" (long enough for me to start researching
how it could be "wrong" and if there was anything I could do about it)

Eventually, I disabled the automatic update. Then, re-enabled it and
noticed the time being correctly updated immediately.

So, either the phone issued a request for the time when I REenabled the autoupdate feature (and that request was honored in short order) *or*,
the time is broadcast at some high update rate so it is "available"
almost instantaneously, regardless of when you NEED it. Re-enabling
the auto update just triggered the daemon that watches for broadcast timestamps.

If the phone was responsible for REQUESTING the time, then the fact
that it was out-of-sync for such a long time suggested it didn't
feel the need to request an update. The daemon responsible for
maintaining it likely spent most of its time sleeping and only
infrequently re-issued such a request (how far can the local
RTC drift between update requests)

If the phone was constantly/periodically TOLD the current time,
then it was obviously ignoring those messages and sticking with
its incorrect knowledge of the current time.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 27/08/2025 07:09, Don Y wrote:

On 8/26/2025 10:03 PM, Jeff Liebermann wrote:

Do cell phones get their time-of-day references from the
cellular network?-a GPS (adjusting for leap seconds)?-a Or both?

In the case of the cellular network, is a timestamp routinely
broadcast?-a Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

I can't answer all your questions.

The phone has a GPS receiver the acts as an RTC (real time clock).-a If
there is a low BER (bit error rate) GPS satellite signal, the phone
will use GPS for displaying time.-a If the satellite signal is absent
or shows a high error rate, it will use the time from the cellular
network.

So, the phone (in this mode) is relying on broadcast data.
How often is this updated?-a 1Hz?

GPS use NMEA-0183 code to regularly deliver the time.-a The GPGGA
sentence includes the current UTC time.-a It's not really broadcasting
because none of the satellites transmit the current time.-a Instead,
the GPS receiver combines the data from at least 3 satellites and
computes the receiver location.
<https://w3.cs.jmu.edu/bernstdh/web/common/help/nmea-sentences.php>
A connected device does NOT poll or query for NMEA-0183 data.-a The
receiver continuously sends NMEA-0183 data.-a Connected device filter
the data stream for the specific sentences (such as GPGGA) that it
wants, and uses that to provide time, location, etc.

I don't know what you mean by "timestamp".-a Are you referring to the
standardized formatting of the data such as ISO 8601
("YYYY-MM-DDThh:mm:ssZ")?
<https://www.iso.org/iso-8601-date-and-time-format.html>
to make conversion to UTC easier?-a Otherwise, I haven't seen the term
used with GPS.

I had a phone that was displaying incorrect time.-a Despite being
configured to "automatically update the time".-a It continued to
do this for "a long time" (long enough for me to start researching
how it could be "wrong" and if there was anything I could do about it)

Eventually, I disabled the automatic update.-a Then, re-enabled it and noticed the time being correctly updated immediately.

So, either the phone issued a request for the time when I REenabled the autoupdate feature (and that request was honored in short order)-a *or*,
the time is broadcast at some high update rate so it is "available"
almost instantaneously, regardless of when you NEED it.-a Re-enabling
the auto update just triggered the daemon that watches for broadcast timestamps.

If the phone was responsible for REQUESTING the time, then the fact
that it was out-of-sync for such a long time suggested it didn't
feel the need to request an update.-a The daemon responsible for
maintaining it likely spent most of its time sleeping and only
infrequently re-issued such a request (how far can the local
RTC drift between update requests)

If the phone was constantly/periodically TOLD the current time,
then it was obviously ignoring those messages and sticking with
its incorrect knowledge of the current time.

How badly wrong was the phone?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/27/2025 12:31 AM, John R Walliker wrote:

On 27/08/2025 07:09, Don Y wrote:

So, either the phone issued a request for the time when I REenabled the
autoupdate feature (and that request was honored in short order)-a *or*,
the time is broadcast at some high update rate so it is "available"
almost instantaneously, regardless of when you NEED it.-a Re-enabling
the auto update just triggered the daemon that watches for broadcast
timestamps.

If the phone was responsible for REQUESTING the time, then the fact
that it was out-of-sync for such a long time suggested it didn't
feel the need to request an update.-a The daemon responsible for
maintaining it likely spent most of its time sleeping and only
infrequently re-issued such a request (how far can the local
RTC drift between update requests)

If the phone was constantly/periodically TOLD the current time,
then it was obviously ignoring those messages and sticking with
its incorrect knowledge of the current time.

How badly wrong was the phone?

Ten or eleven minutes. This "tracked" for quite a long time
until I hit on the idea to turn OFF the automatic update.
And, then, turn it back on.

I was waiting for a phone call and didn't know which line the
call would come in on. (My telephone system screens calls so
wouldn't notify me of a call from this "unregistered" caller
which meant I had to watch the phones directly for activity
as their ringers are silenced)

So, I had two phones nearby. I would periodically "awaken" one
(screen saver) to see the current time. At one point, I recall
seeing 2:11AM. Some time later, I saw 2:10AM -- obviously, on
the *other* phone. Then, awakened both so I could see their clocks side-by-side.

I kept watching them out of curiosity -- expecting one (or the other)
to sync back with it's partner (same cellular provider for each).

After some time, I realized this was a "sticky" problem and
started to research it ("Is there a way to deliberately introduce
an offset into the displayed time -- like folks who set their
clocks ahead to avoid being late for appointments?")

Then, checking on-line resources to identify which one(s) were in error
and started researching the source of the time reference. Verifying
that both had "service" and good signal (no idea what their GPS
signal qualities were as the phones don't report that)

I.e., it's not a "timezone" error. Or, a "rounding error", etc. The
offending phone was clearly "off" -- compared to the other, compared to internet time sources, compared to the PC (NTP synced), etc.

The fact that the error persisted for so long got me wondering how
the software could (presumably) ignore the fact that it was out
of sync... Has this been happening regularly? How would I know...
unless I kept checking a second timepiece?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 2025-08-27 04:00, Don Y wrote:

Do cell phones get their time-of-day references from the
cellular network?-a GPS (adjusting for leap seconds)?-a Or both?

In the case of the cellular network, is a timestamp routinely
broadcast?-a Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

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.
--
Cheers, Carlos.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 27/08/2025 11:27, Carlos E.R. wrote:

On 2025-08-27 04:00, Don Y wrote:

Do cell phones get their time-of-day references from the
cellular network?-a GPS (adjusting for leap seconds)?-a Or both?

In the case of the cellular network, is a timestamp routinely
broadcast?-a Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

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.

-a-a-a Notice that GPS and NTP transmits UTC time, which would have to
-a-a-a be corrected for the estimated time zone, which is not necessarily
-a-a-a 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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 2025-08-27 13:24, John R Walliker wrote:

On 27/08/2025 11:27, Carlos E.R. wrote:

On 2025-08-27 04:00, Don Y wrote:

Do cell phones get their time-of-day references from the
cellular network?-a GPS (adjusting for leap seconds)?-a Or both?

In the case of the cellular network, is a timestamp routinely
broadcast?-a Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

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.

-a-a-a-a Notice that GPS and NTP transmits UTC time, which would have to
-a-a-a-a be corrected for the estimated time zone, which is not necessarily >> -a-a-a-a 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.-a 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.

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.
--
Cheers, Carlos.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/27/2025 3:27 AM, Carlos E.R. wrote:

On 2025-08-27 04:00, Don Y wrote:

Do cell phones get their time-of-day references from the
cellular network?-a GPS (adjusting for leap seconds)?-a Or both?

In the case of the cellular network, is a timestamp routinely
broadcast?-a Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

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.

Both phones are using the same provider.

The "broken" phone came up with the correct time when "auto update" was disabled and then reenabled (likely causing the first line of code to be "reacquire_network_time()")

I.e., the software is deliberately ignoring the correct time.
This could be intentional -- an effort to keep the time monotonically increasing and not "jump" backwards. But, if one can manually set
the time to any value, there's not much value in that.

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

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

I have an old 3G (no longer supported) phone that uses an NTP app
to set the time (because there is no provision for doing so *in* the phone)

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On Tue, 26 Aug 2025 23:09:42 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 8/26/2025 10:03 PM, Jeff Liebermann wrote:

Do cell phones get their time-of-day references from the
cellular network? GPS (adjusting for leap seconds)? Or both?

In the case of the cellular network, is a timestamp routinely
broadcast? Or, does the client query the network?

[My guess is network broadcast timestamps at some relatively
high rate]

I can't answer all your questions.

The phone has a GPS receiver the acts as an RTC (real time clock). If
there is a low BER (bit error rate) GPS satellite signal, the phone
will use GPS for displaying time. If the satellite signal is absent
or shows a high error rate, it will use the time from the cellular
network.

So, the phone (in this mode) is relying on broadcast data.
How often is this updated? 1Hz?

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

GPS use NMEA-0183 code to regularly deliver the time. The GPGGA
sentence includes the current UTC time. It's not really broadcasting
because none of the satellites transmit the current time. Instead,
the GPS receiver combines the data from at least 3 satellites and
computes the receiver location.
<https://w3.cs.jmu.edu/bernstdh/web/common/help/nmea-sentences.php>
A connected device does NOT poll or query for NMEA-0183 data. The
receiver continuously sends NMEA-0183 data. Connected device filter
the data stream for the specific sentences (such as GPGGA) that it
wants, and uses that to provide time, location, etc.

I don't know what you mean by "timestamp". Are you referring to the
standardized formatting of the data such as ISO 8601
("YYYY-MM-DDThh:mm:ssZ")?
<https://www.iso.org/iso-8601-date-and-time-format.html>
to make conversion to UTC easier? Otherwise, I haven't seen the term
used with GPS.

I had a phone that was displaying incorrect time.

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.

Despite being
configured to "automatically update the time". It continued to
do this for "a long time" (long enough for me to start researching
how it could be "wrong" and if there was anything I could do about it)

Eventually, I disabled the automatic update. Then, re-enabled it and
noticed the time being correctly updated immediately.

So, either the phone issued a request for the time when I REenabled the >autoupdate feature (and that request was honored in short order) *or*,
the time is broadcast at some high update rate so it is "available"
almost instantaneously, regardless of when you NEED it. Re-enabling
the auto update just triggered the daemon that watches for broadcast >timestamps.

If the phone was responsible for REQUESTING the time, then the fact
that it was out-of-sync for such a long time suggested it didn't
feel the need to request an update. The daemon responsible for
maintaining it likely spent most of its time sleeping and only
infrequently re-issued such a request (how far can the local
RTC drift between update requests)

If the phone was constantly/periodically TOLD the current time,
then it was obviously ignoring those messages and sticking with
its incorrect knowledge of the current time.

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:
<https://www.visualgps.net>
The free stuff is quite good.
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On 8/27/2025 8:54 AM, Jeff Liebermann wrote:

On Tue, 26 Aug 2025 23:09:42 -0700, Don Y

So, the phone (in this mode) is relying on broadcast data.
How often is this updated? 1Hz?

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

That would be consistent with the near instantaneous "correction"
that occurred when the auto-update was switched to off and then on.
If broadcasts were less frequent (e.g., WWV/CHU rates), then the
odds of such a quick update would be considerably lessened
(one should be able to test this by manually setting an incorrect
time and then enabling the update and waiting to see how quickly
it resyncs)

I've seen explanations that claim the cell towers capture GPS timestamps
and use them to update THEIR clocks -- which are then used to embed
timestamps in "network messages".

However, having the phone rely on the GPS source seems more likely
in that it doesn't rely on the quality of the network signal
(which was observed to be "good" on both phones) but, instead,
on the phones' views of the satellite constellations (typically
worse indoors than the network signal -- and, no easy way to
determine/verify the "quality" of that signal)

"Not seeing the sky" is a more palatable explanation than "some
latent bug in the latest firmware update (that no one has thought to fix)"

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.electronics.design

On Wed, 27 Aug 2025 08:54:51 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

On Tue, 26 Aug 2025 23:09:42 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

So, the phone (in this mode) is relying on broadcast data.
How often is this updated? 1Hz?

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

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" <https://en.wikipedia.org/wiki/GPS_week_number_rollover>

"GPS Week Number Rollover April 6, 2019" <https://www.gps.gov/support/user/rollover/>

Your Old GPS Receiver Will Never Work Again... Magellan 2000 <https://www.youtube.com/watch?v=55vbWXTx6Kc>
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558
--- Synchronet 3.21a-Linux NewsLink 1.2