# [time-nuts] GPS Time to Year?

Magnus Danielson magnus at rubidium.dyndns.org
Thu Jan 22 18:58:17 EST 2009

```Tom Van Baak skrev:
>> Hi:
>>
>> It's my understanding that the slowest time data from GPS is the 10 bit week
>> number.
>> How does a GPS receiver come up with the current Year?
>>
>> --
>> Have Fun,
>>
>> Brooke Clarke
>
> Hi Brooke,
>
> Good question. You are correct that this 10-bit week number
> wraps once every 2^10=1024 weeks which is once about every
> 20 years. It's not the slowest GPS data, see below *.
>
> Other GPS fields also wrap (more quickly) in a binary way.
> Most wrist watches, for that matter, wrap 60 seconds, or 60
> minutes, or 12 hours.
>
> Note:
> GPS week 0 started MJD 44244 = 1980-01-06
> GPS week 0 (1024) started MJD 51412 = 1999-08-22
> GPS week 0 (2048) starts MJD 58580 = 2019-04-07
> GPS week 0 (3072) starts MJD 65748 = 2038-11-21
>
> The ways GPS receivers come up with the current year are:
>
> 1) Since time moves forward only, the real year can't less than
> what the year was yesterday. So when a GPS receiver on, say,
> Sunday morning April 4, 2019 sees that the GPS week is now 0
> while last night the week was 1023, the GPS receiver can be very
> sure that the year is still 2019 and not 1980 or 1999 or 2019. As
> long as a GPS receiver has NVRAM you're all set.
>
> 2) The real year can't be less than the year the GPS receiver was
> manufactured. If the firmware sees GPS week 491, is has the
> option to decide if that week means 0+491 (June 1989) or 1024+491
> (January 2009) or 2048+491 (September 2028). With a +/- 10 year
> margin the GPS receiver can pick the correct one.
>
> On the other hand, those of us with boat anchor GPS receivers from
> August 1999 know that firmware isn't always perfect.'
>
> 3) The real year can be obtained from external sources. Many GPS
> receivers are now embedded into cell phone or internet-enabled
> devices so obtaining a hint at the current date is easy. One may
> even know the date&time well before the first GPS signal lock.
>
> 4) The real year can't have fewer leap seconds than the previous
> year. So if you see that the GPS week number is 0 and the UTC
> vs. TAI leap second count is around 20 seconds you know it's
> GPS week 0 and year 1980. If the leap second count is closer to
> 32 seconds you know it's GPS week 0(1024) and so year 1999.
> If the count is closer to, say, 44 seconds, then you can be safe
> that it's GPS week 0(2048), or year 2019. Not perfect, but it will
> work fine for our lifetimes and more.

You could use leap second counter as a rought estimate to get the right
1024 week interval. Naturally, if leap seconds is no longer inserted
that would break that algorithm. I wonder if this hint have been used by

You can also use a CMOS backed clock, which many receivers have or there
is an external option for a backup battery. That hint is usually valid
enought. Also, the CMOS clock can be maintained when running. Storing
last seen leap second and week number along with date at time of storage
in the CMOS backup memory could also be usefull.

Cheers,
Magnus

```