Hello Peter,
SLClient in Java and ObsPy only pass on the packets as received from the server. The packet may contain a data trace (in miniseed), which includes a starttime and sampling_rate. The data trace, starttime and sampling_rate are exactly as sent by the server. So, unless other ObsPy developers have added some kind of timing checks and modifications, the difference in sampling_rate you see is from up-stream of the server (perhaps the network makes a time correction every day at midnight)?
I have spend many hours dealing with this problem in SeisGram2K SeedLink monitor. Besides an occasional timing shift as you mention, it is also possible that the nominal sample rate multiplied by the number of samples does not agree with the start time of the data in the next packet. One has to check each theoretical packet end time and compare with the start time (minus 1 sample) of the following packet, and adjust the reference time somewhere in the trace data in memory to compensate. And/or estimate a real sampling rate. Effectively, as time goes on, earlier samples in memory may move around in time! There are other associated checks that are needed, for example real gaps where there is no data, deal with apparent or real overlaps, …
Best regards,
Anthony