handled in re- ceivers that are already in the field. This is because the original GPS signals outputting GPS calen- dar information (using the GPS timescale) carry the GPS week number in a 10-bit field. This field counts the week number since the epoch of the GPS timescale (6 January 1980). Of course, a 10-bit value overflows, or rolls over, after 1024 weeks (approximately 19.6 years). This has already happened twice in the history of GPS, first in August 1999 and second in April 2019. Modernized signals available on new generations of satellite use 13-bit representations for the GPS week that will largely avoid this problem in the future, but it is still a problem for receivers of the widely used L1 signals. The most common approach to solve this problem was to use the idea of a base date in the receiver software. Take an example of a date before the last rollover, say 22 June 2015. In the GPS calendar, this is Julian day 173 in GPS week 1850 (the Julian date is simply the day number of the year with January 1 starting as day 1). But notice that the week number is already greater than 1024, which is because the week number has already rolled over once. So, 22 June 2015 is in week 826 of the second set of weeks from 1024-2047. The GPS L1 legacy signal will only show that it is week 826, since they only have 10 bits to represent the value 1850. So, what a receiver manufacturer does is to release their software that is hard coded using a base date-a date such as the compilation date of the software. So, software compiled on 22 June 2015 assumes that the date it receives from GPS can never be before that date. If the week number the receiver receives from GPS is 826 or greater, then it assumes that the date is in the range of 22 June 2015 to 6 April 2019 (it adds 1024 to it, giving a range of 1850-2047). If the week number is less than 826, then the current date must be after another rollover, and be in the date range of the next set of 1024 weeks (7 April 2019 onward) and SO it adds 2048 to the received week numbe