12 November 1998 
I asked one of our GPS engineering consultants who is well versed in GPS technology theory and practice to tell us what spectacular event would happen to a GPS that was NOT "Y2000 compliant".   Not much  says he.  Read on for further comments.  Since he does  not have  time  to respond to questions from the newsgroup,   he  has asked that his name not be published.  Here are his comments.
Joe,  you  wanted  to post my  comments about  the  Y2k  and  EOW  "controversy"  (let's  see now, that means End of World  in  Year 2000, doesn't it, like the television psychics want to  predict).  Well,   here  is  The Short Version (consider  it  an  abstract).  Consider  this  oversimplified. But I note that at least  one  of  your  readers   won't  be satisfied with anything  less  than  an  official  manufacturer's certifying stamp on each unit,  accompanied  by  an international press conference  and  appearances  on Oprah,  Nightline,  and Larry King Live and attested to  by  Bill Clinton  (;->).

Hey,  ya know what? As far as position and navigation  goes,  Y2K (and any other artificial calendar counting time) doesn't  matter one  bit to a GPS receiver. The position of the SV is found  from the orbital elements and the difference between the epoch of  the element set as transmitted in the navigation message and the time of transmission of the message. It's only a _difference_ in time,  not the absolute time. And both the orbital element time and  the message  time are contained in the message. The computer  doesn't care whether you are measuring on a Gregorian calendar, a  Moslem calendar,  a Chinese calendar, a Jewish calendar or one you  just made up. The algorithm just takes the times given in the  message and  calculates the current Mean Anomaly, from which you get  the True  Anomaly, from which you ultimately get the position of  the SV  in  GPS  coordinates (NOT lat/lon, UTM,  or  other  geography units). The only place the date appears in some sort of  everyday calendar format is on your display screen.

And  as  has been pointed out many times before,  the  receiver's clock is, at most, only used to get the initial search configuration. It is _not_ used for the PVT solution iteration  (Position-Velocity-Time).  When you put your receiver in free  search  mode ("autolocate"),  it doesn't even use its own clock. The  "message received" time is determined as part of the solution in  deriving the  pseudoranges  for  each satellite used.  Sort  of  like  the lat/lon  vs UTM in 100 different datums. The number  shown  isn't what  the computer in the GPS uses anyway - it's only  there  for display  purposes.  The  system coordinate system  is  an  Earth-centered    Earth  fixed  Euclidean  system,  no  latitudes,   no Eastings.  Hey,  guess what? It's like GPS time vs  UTC  vs  your local  standard or daylight time. The GPS uses GPS time  for  its computations,  then  displays  whatever you  want.  In  the  vast majority  of units (all the consumer toys and virtually  all  the marine and air navigation units) you can't display the GPS  time, even if you want to. The time units are 1/403200 of a week, which is  about 1.5 seconds, not seconds or nanoseconds (it's  1/806400 of a fortnight, though (8>D).

The  one  problem is the week rollover. And, ya know  what?  That really  is only a problem for a unit that doesn't have a  current ephemeris  for  a given SV for a short time around  the  rollover date. If you are more than a few hours past the rollover, all the SVs  will  have  a new ephemeris,  your internal  clock  will  be counting  up mod 1024 weeks, and you are fine. The problem  comes when you have an ephemeris which is epoch 1023.xxx weeks and your clock has rolled over to 1024.yyy, which means it reads 0.yyy. It will  compute  a  negative time, unless your unit has  a  way  of catching  that (as do all units from the major  manufacturers  in the  past 5 or 10 years). But, since the ephemeris is uploaded  a couple  times a day, at worst your position computation  will  be wrong  for a day or so in August 1999. My understanding from  the manufacturers  I  have  talked  to (4  of  the  major  ones),  or indirectly  from ones Joe, Sam, and Jack have  had contact  with, is  that current units catch even that small problem. Some  older units will have a hard time locking on because they are calculating  visibilities from the canonical orbital elements  stored  in ROM,  but  once they have locked on and updated  their  ephemeris set,  they will give the right location  and time of day (but not the right calendar day, just off by about 230 days).

Sigh!  What it comes down to is that there are a bunch  of  folks who  have absolutely no concept of how orbital  calculations  are done. Sorry folks,  the Earth isn't flat, it isn't the center  of the universe, and even the Sun isn't the center of the  universe. I  groan  every  time I see  another  of  these  anthropocentric, ethnocentric, or worse yet, egocentric postings that claims  that the poster's way of viewing things is the only way, and the  rest of  the universe can --- whoops, the universe can't jump  in  the lake  can it? (My calendar is the only one, my foot ruler  is  the only way to measure, my view of the world is the only correct one -so there!)

I  edited  the above very slightly for clarity(?).   If  anyone  has questions/comments,  please post directly to the newsgroup.

Joe Mehaffey

Note:  One DOD GPS analyst suggests that the above is overly optimistic and that there are a lot of unknowns out there in the Y2K arena.  Industry people however believe that THE UNITS THEY HAVE TESTED for EOW and Y2K compliance will work just fine.   I guess the prudent thing is to not have yourself in a life threatening situation in case of GPS failure immediately before or immediately after EOW or Y2K rollover.  I personally trust manufacturer's engineers and when they say they have tested a particular unit and all is well,  I fret no more.

Joe Mehaffey