RINEX v3 doesn't correctly handle invalid xmitTime

[peci1]

gnsstk/core/lib/FileHandling/RINEX3/Rinex3NavData.cpp

Line 1017 in cbba16f

xmitTime = RNDouble(line.substr(n,19)); n+=19;

According to the standard, if the xmitTime is set to .9999+e09, then it should be treated as invalid/unknown. However, the library doesn't do this and uses this value as if it were proper.

The following call to fixTimeGPS() then destroys navOut.xmitTime by adding this invalid value to a GPS week nr.:

gnsstk/core/lib/NewNav/RinexNavDataFactory.cpp

Line 344 in cbba16f

fixTimeGPS(navIn, *gps);

Apparently, this one place where the invalid value destroys things could get easily fixed by treating the invalid value as 0, but I'm not sure whether there are other places where it could make problems.

One of the problematic RINEX v3 files is e.g. this one: https://igs.bkg.bund.de/root_ftp/MGEX/BRDC/2024/001/BRDC00WRD_S_20240010000_01D_MN.rnx.gz . E.g. the very first nav message:

E08 2023 12 31 23 50 00-2.009316231124e-04-5.940137270954e-12 0.000000000000e+00
     1.500000000000e+01-1.201562500000e+02 2.852261665290e-09-3.006433072931e+00
    -5.470588803291e-06 1.602121628821e-04 8.979812264442e-06 5.440613040924e+03
     8.580000000000e+04-8.195638656616e-08 4.684350206789e-01-9.313225746155e-09
     9.662984159677e-01 1.517812500000e+02 7.945787833385e-01-5.399510625576e-09
    -2.142946405177e-12 5.170000000000e+02 2.295000000000e+03 0.000000000000e+00
     3.120000000000e+00 0.000000000000e+00-3.725290298462e-09-4.423782229424e-09
     9.999000000000e+08   

You can see the 9.999000000000e+08 in the very last position. This is what makes problems.

---

Reproducer:

gnsstk::NavLibrary lib;
gnsstk::NavDataFactoryPtr fac = std::make_shared<gnsstk::RinexNavDataFactory>();
fac->addDataSource("BRDC00WRD_S_20240010000_01D_MN.rnx");
lib.addFactory(fac);
std::cout << gnsstk::printTime(gnsstk::CivilTime(lib.getInitialTime()), "%Y-%m-%d %H:%M:%f") << " --- "
          << gnsstk::printTime(gnsstk::CivilTime(lib.getFinalTime()), "%Y-%m-%d %H:%M:%f") << std::endl;

Initial time is wrongly in year 2055 and final time is also weird:

2055-8-30 22:0:0.000000 --- 2023-12-25 4:0:0.000000