r (giving a week number of 2048 and upward). This means the receiver will correctly report the date from the start of GPS week 1850 (1024 + 826) to the end of week 2873 (1850 + 1023). But what happens when the week number exceeds 2873 on 28 January 2035? The receiver will revert to the original base date in June 2015! The thing to un- derstand is that the GPS rollover problem might arise in your receivers at a date not aligned with the well-publicized end of a 1024-week GPS era. The solution to this internal rollover problem is to simply release a new version of the software with a later base date, SO it is not a difficult problem to fix. Many receivers, even smart phones and tab- lets, have used this approach and fix the base date problem through automatic updates to their soft- ware. More concerning to operators though, is that there are models of a very widely deployed GPS PRTC/T-GM that will suffer this problem in September 2022, and they do not have an automatic update feature like a smart phone. The lesson is to make sure the software in your receivers is kept up to date. 12.6 Summary The goal of this chapter was to cover the "life cycle" of steps that an operator might take to decide upon, roll out, and operate a timing solution. An additional bonus was to tie up some loose ends and include additional material that did not seem to belong elsewhere in the book. To begin with, the chapter provided a broad overview of the features and components that an engineer should look for in a network element that performs well as a clock. The section on hints for designing a timing vendor selection process and then the testing of timing was meant to share with operators the authors' experience in these important areas. This experience is gained from answering literally hundreds of technical RFPs and RFIs and helping just as many customers perform timing testing on network equipment and PTP/SyncE clocks. Testing is a very specialized and detail-oriented activity that a lot of engineers really struggle with, SO this chap