# Title Clarification of the handling of leap seconds # Moderator # Requirement Summary In order to correctly compute timestamps of measured variables where the reference date in the `units` attribute and the point in time of the measurement are separated by one or more added (or removed) leap seconds, it is required to know if leap seconds are to be counted or not. # Technical Proposal Summary Add a sentence like the following to [§4.4 Time coordinate](http://cfconventions.org/cf-conventions/cf-conventions.html#time-coordinate): > Leap seconds are ignored during the calculation of all dates and times. That > is, they are treated as if all clocks stand still during the presence of an > added leap second or as if the clocks jump by one second across a removed > leap second (if that should ever occur).
# Benefits Anyone who is working on high-frequency (sub-minute intervals) measurement data will benefit from this clarification. Without this change, time series wich cross an added (or removed) leap second can not be stored unambiguously using CF Conventions. Furthermore, there there is considerable demand of specifying time in `seconds since 1970-01-01` for historical reasons or other reference date far from the measured point in time. This specification is also not exact if the handling of leap seconds is not defined. Errors due to different handling of leap seconds between data producers and data consumers lead to bugs which are hard to track and annoying. These errors can likely be reduced if handling of leap seconds is specified unambiguously. # Drawbacks If leap seconds are ignored, **measurements which happen exactly on the leap second can not be represented**. This however is currently already the case in practice. In order to fix this additional issue, proper handling of leap seconds, TAI clocks and UTC clocks would have to be included. That topic is already being discussed in #148 and thus should not be part of this issue. Once #148 is settled (I hope that will be soon!), the added statement will not be true in general, but will be dependent on the specified `calendar` or other attributes and thus might need to be reworded slightly. I however don't think that this issue will affect the possibility to implement #148 in any negative way. # Status Quo Leap seconds are not mentioned anywhere in CF Conventions. Usual libraries like `cftime` or `numpy` ignore leap seconds, but there's no specification that this library must be used and that what these libraries do is how it is intended to be. Thus for all implementations which I am currently aware of, nothing will change in practice, but discussions about how to implement custom solutions will become much simpler. # Associated pull request none yet # Detailed Proposal (this is the same as above) Add a sentence like the following to [§4.4 Time coordinate](http://cfconventions.org/cf-conventions/cf-conventions.html#time-coordinate): > Leap seconds are ignored during the calculation of all dates and times. That > is, they are treated as if all clocks stand still during the presence of an > added leap second or as if the clocks jump by one second across a removed > leap second (if that should ever occur). --- This issue is intentionally separate from #148. My hope is that this issue can be settled a lot quicker. I also think that these really are two different concerns as #148 would add additional, desirable functionality while this issue only removes ambiguity from the current specification. It is incomplete in the sense of the mentioned drawbacks in order to make the scope smaller and simpler to implement. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/313 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
