GB337 27.07.4 Remove gps_clock, strike 2

[wg21bot]

gps_clock is a unilateral reference to a US service and has no place alone in the ISO standard The GPS GNSS service is owned, maintained and controlled by the US government and while Satellite timing and position usage has become all but ubiquitous in many applications a modern GNSS receiver is capable of receivng updates from multiple GNSS constellations to ensure coverage and security. If GPS is represented then other national and internationally maintained services should be included, Glonass, Beidou, Galileo to name but 3. Each of these have different operating parameters, most notably the epoch and the application or not of leap seconds. ​https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS While Galileo and Beidou do not respect leap seconds, GLONASS does and GLONASS transmits at a constant offset of 3 hours relative to UTC (being Russian standard time). Other features of gps, such as the week rollover (an epoch defining event and which occurs every 19 years, the most recent being this April 2019) are not represented in the gps_clock. If one purpose of providing a gps_clock is to allow the comparison of gps data to other clocks then epoch rollover probably ought to be recognised, though hopefully it will become a thing of the past as increasingly gps satellites are upgrading to a large week counter)

Proposed change: Remove gps_clock

[wg21bot]

See also GB336 #332.

[HowardHinnant]

When I added gps_clock to my date/time library three and a half years ago, playing politics by promoting the US navigation system while ignoring those of China, Europe, and Russia was the last thing on my mind. And that library with field experience is what was subsequently proposed for the international C++ standard in 2017.

In hindsight I can certainly understand how this action has the appearance of political favoritism. And for that I apologize. It was not my intent. But appearances are important, and I recognize that.

I have no objection whatsoever to more clocks being introduced which model the navigational time standards of China, Europe and Russia, as long as they follow the API style of gps_clock (which itself follows the style of other chrono::clocks).

However it is too late in the C++20 cycle to introduce those clocks for C++20. And I think it would be petty to remove gps_clock for these political reasons. The example implementation of gps_clock has publicly documented users (see https://github.com/HowardHinnant/date/issues and https://stackoverflow.com/). It would be punitive punishment for these clients to deny them a complete migration to C++20, because of non-technical reasons. I would be happy to immediately begin implementations of these other navigational time standards in my https://github.com/HowardHinnant/date repo, or accept P/R's submitted by others of the same. Now is the time to be gathering field experience for relatively minor C++23 proposals.

The existing field experience with gps_clock is positive. The majority of clients are not using it. However there is documented and public evidence that it is being used by a minority via questions and feature requests. Furthermore a superficial survey shows similar functionality in Java, JavaScript and python. Additionally this survey shows that a significant amount of C++ code is doing GPS time computations outside of the chrono system using type-unsafe int and long to represent various units of time. There is a need here. And chrono can be used to promote modern type-safe programming practices.

Removal of gps_clock would not only harm existing date::gps_clock clients, but it would also harm the chances of C++23 adoption of additional navigational time standards.

As for "week rollover" there is no need to model every aspect of a GPS receiver. gps_clock models the GPS time standard, not a GPS receiver. It only models the time duration since the first Sunday of January, 1980 00:00:00 UTC, and the unique mapping of gps time to civil time which counts leap seconds differently than UTC. There are no 61 second minutes. It instead shifts the civil time mapping by 1 second. This is useful functionality to help the programmer through what is a very confusing relationship between UTC, GPS and the civil calendar.

See the example code here: https://github.com/cplusplus/nbballot/issues/332#issuecomment-549344721 which shows how easy it is for the client to model week rollover himself. This is beneficial because different clients come with different inputs for the problems they have to solve. For example some clients might come with raw GPS feeds, while others come with a double representing the sum of seconds since the GPS epoch. Modeling only the time standard, and not the navigational receiver, divorces the standard from such details. And handling such details by the client is easy within the chrono library. The hard part is epochs and leap seconds which C++20 chrono can handle.

[tituswinters]

LEWG in Belfast: Rejected. No consensus for change.