Properly reading MiniSEED files with microsecond wrap arounds

[krischer]

This PR enables ObsPy to read MiniSEED files with microseconds wrap arounds.

Times in SEED have a .0001 second field which according to the spec must be in 0-9999. I've encountered a file that has a value of 10000.

ObsPy now interprets these as a additional seconds. libmseed internally appears to do the same so I guess these files were encountered before.

[Jollyfant]

Looks good. I can pass review if tests complete. How about raising a warning when microseconds > 10000. It might be indicative of two fishy bytes instead of silently wrapping around to seconds.

[Jollyfant]

Not because I feel very strongly about this but because reviewing makes me feel like I need to contribute.

[krischer]

Not because I feel very strongly about this but because reviewing makes me feel like I need to contribute.

Oh please do :-) We really need more people to review changes in any case. And in general people who are familiar with large pieces of the code base.

How about raising a warning when microseconds > 10000. It might be indicative of two fishy bytes instead of silently wrapping around to seconds.

Good idea and done in the latest commit. It now looks like this:

In [2]: obspy.read("./tests/data/microsecond_wrap.mseed")
/Users/lion/workspace/code/obspy/obspy/io/mseed/util.py:432: UserWarning: Record contains a fractional seconds (.0001 secs) of 10000 - the maximum strictly allowed value is 9999. It will be interpreted as one or more additional seconds.
  category=UserWarning)
/Users/lion/workspace/code/obspy/obspy/io/mseed/core.py:423: InternalMSEEDReadingWarning: readMSEEDBuffer(): Record with offset=0 has a fractional second (.0001 seconds) of 10000. This is not strictly valid but will be interpreted as one or more additional seconds.
  warnings.warn(*_i)
Out[2]:
1 Trace(s) in Stream:
IM.NV32..BHE | 2008-01-08T04:58:06.000000Z - 2008-01-08T04:58:12.900000Z | 40.0 Hz, 277 samples

It's a bit verbose as its raised twice. The first one is raised once per file - its from the Python part that reads the very first record to set-up some stuff. The second one is in the C part and will be raised for every single record that has this.

I think this is okay as it does violate the standard. If people are annoyed by this they can always just catch the warnings. What do you think?

[Jollyfant]

Ok nice. I think it's better to raise the warning and risk annoying someone than to ignore it. It should only print the warning twice if the first record has the problem, which would be very rarely.

[krischer]

Now passes CI - ready for review!

[Jollyfant]

Comprehensive change and descriptive tests. Ready to be merged.