Clock corrections for MJD 0 do not register

[dlakaplan]

In time.dat it has entries:

   MJD       EECO-REF    NIST-REF NS      DATE    COMMENTS
=========    ========    ======== ==    ========  ========
 00000.0        0.0         0.0   @                 Barycenter: no correction
 99999.0        0.0         0.0   @                 Barycenter: no correction

which are supposed to be for a default barycenter. Similarly, the correction file for CHIME is:

   MJD       EECO-REF    NIST-REF NS      DATE    COMMENTS
=========    ========    ======== ==    ========  ========
 00000.0        0.0         0.0   y                 CHIME -- no clock corr
 99999.0        0.0         0.0   y                 CHIME -- no clock corr

but as far as I can tell from clock_file.py it will reject any times before 39000:

            # Parse MJD
            try:
                mjd = float(l[0:9])
                if mjd < 39000 or mjd > 100000:
                    mjd = None
            except (ValueError, IndexError):
                mjd = None

I'm not sure if this is why so many tim file result in messages like:

Data points out of range in clock file '/Users/kaplan/pythonpackages/PINT_dlakaplan/src/pint/data/runtime/time.dat'

If I change the starting MJD for the CHIME file to 50,000, then for a file containing only CHIME TOAs that message goes away. It wasn't a big deal, but it was causing some confusion.

This is easy to fix, but it could be done via:
changing the minimum allowable MJD
and/or
changing the starting MJD of the clock files

[dlakaplan]

@almcewen0

[aarchiba]

Part of the confusion is that TEMPO/TEMPO2 used to not do any remotely sensible extrapolation of clock corrections, so people would put in a clock correction for MJD 99999 in hopes that the interpolation would do better. These don't represent actual clock data, and can confuse a naive reader about what times the clock correction file actually covers. Handling of data before the first, I think, is similar. Nevertheless we do need a way to represent these "clock correction is zero forever" files, and maybe also to correctly handle the fake-extrapolated clock files. I think special cases may be in order.

[aarchiba]

#1239 improves on the handling of this too but it's sorted.