PINT misidentifies TOA format

[dlakaplan]

I was sent a tim file that was apparently valid for TEMPO2, but which PINT could not parse. Entries were like:

FORMAT 1
MODE 1
 uwl_191009_015952.0000_0000.rf.pTF 1102.00000000 58765.09374976854768846 22.04600 pks
 uwl_191010_000912.0000_0000.rf.pTF 1102.00000000 58766.02430580012498496 23.74000 pks
 uwl_191012_013412.0000_0000.rf.pTF 1102.00000000 58768.08628513784793768 16.29100 pks
 uwl_191013_013912.0000_0000.rf.pTF 1102.00000000 58769.08628494704621659 18.55400 pks 
 uwl_191014_011651.0000_0000.rf.pTF 1102.00000000 58770.06840417512788122 21.57900 pks
 uwl_191015_063631.0000_0000.rf.pTF 1102.00000000 58771.28385332518061546 23.07400 pks
C uwl_200817_060611.0000_0000.rf.pTF 1102.00000000 59078.27291615603383690 18.41200 pks
 uwl_200830_103538.rf.noscl.paz2.pTF 1115.36200000 59091.46028405561133567 14.03300 pks

so the initial space led PINT to think that these were Parkes format, and then it barfed. Oddly, it managed to get through some of these and only died on the last one (maybe it had too many periods to interpret as a float?). Once I removed the initial space it was all OK.

I don't know how rigid the parsing is in TEMPO2, or if this initial space is expected/should be allowed.

It wasn't a hard fix but the error messages weren't helpful, so we could also consider some fallback parsing (try multiple formats?).

[dlakaplan]

OK, I see. The line that failed just happened to have a leading space and a period in character 41, so it was identified as Parkes. The others were correctly done.

Would it make sense to update:

    elif fmt == "Parkes":
...
        try:
            ...
        except ValueError:
            MJD,d = _parse_toa_line(line, format="TEMPO2")

I don't know enough about the formatting specs to know if this would fail in other ways or create other problems.