UTC DateTime: make it leap second proof

[petrrr]

The leap second is approaching. On Jun 30 the next leap second will be add. As far as I know UTCDateTime (and to a big part Unix) uses a simplified approach to store time, which does not contemplate the fact of leap seconds in UTC at all. Despite it is a rare event, it would be great if ObsPy could handle them correctly.

Basically this requires the following:

• accept that in seconds = 60 or time = 23:59:60 under some conditions might be a valid value. It could also become an alias for time 00:00:00 +1day, which might be useful in some occasions.
• time differences across very special dates need to be corrected by the leap second delta (so far only +1)
• maybe the underlying datetime representation might need to change.

Any opinions on this?

[krischer]

Yea I also thought about this. The 60 seconds thing might be a bit difficult but I did not yet look into it. Time differences are fairly simple to do and the date representation is also fine as we employ a double precision timestamp which the operating system adjust to the change. The most crucial change is the time difference but that again is fairly simple to do - libmseed has support to use a file in a certain format so we should just do the same in the UTCDateTime class.

[petrrr]

I agree, that probably the time diff, is the most important part, as at least it will avoid inconsistencies when trying to get a time series across the limit. But of cause there will be some other issues (with smaller relevance maybe) like plotting etc.

[danauerbach]

Currently wrestling with the processing of the "extra" leap second of data. Could Obspy use the libmseed function ms_readleapseconds(char *envvar) to read a (user supplied) IETF standard leap second file based on a documented env var to use?

The goal being, at minimum, to provide a way for Obspy to know that the 'extra' leap second data is not an overlap.

[krischer]

This is on our list in the near future in any case (help is very welcome of course). We'd probably just write our own parser for the file, ship with a version, and also allow for an env variable to point to a user specified one for people that do not want to upgrade ObsPy all the time.

This would somehow have to be synced with libmseed but that should prove no big hurdle.

If someone wants to give it a go: I think its only the __add__ and __sub__ method that need adjustment. Dealing with timestamps representing the exact leap-second will be very hard as datetime does not support it and its likely also not needed.