@martinjuckes You are exactly correct about the proper interpretation of time around a leap second.
A large number of existing observational datasets obtain time as a UTC time stamp and then convert it to an elapsed time since an epoch using "naive" software which does not take leap seconds into account. A growing number of observational datasets directly acquire precise and accurate elapsed times since an epoch, either from a GPS unit or a satellite operating system, or they acquire time stamps that don't include any leap seconds (TAI time stamps, for example) and convert them using naive software. As it currently stands, those creating the time variables have no way to indicate which way the data was acquired, and users have no way to tell how they should interpret the values. As I mentioned, the question is often unimportant because the time resolution of the data acquired is coarse enough that it doesn't matter, or because it comes from non-physical systems such as models. When it the question is important, it can be critical. The CF explanation of the calendar attribute is > In order to calculate a new date and time given a base date, base time and a > time increment one must know what calendar to use. For this purpose we > recommend that the calendar be specified by the attribute calendar which is > assigned to the time coordinate variable. We are trying to make a way for people to indicate what they have done when it matters without burdening those for whom this is not important. Here's a table showing the impact of different processing sequences with respect to leap seconds when attempting to obtain a UTC time stamp from a time variable with an accurate UTC epoch date and time (assuming there are one or more leap seconds within the time variable range or since the epoch date and time). Time Source | Conversion to Time Var | Accurate Time Var? | Conversion from Time Var | Result ---------- | ---------------------- | ------------------ | ------------------------ | ------ UTC time stamp | Naive | No | Naive | Correct UTC UTC time stamp | Naive | No | Smart | Incorrect UTC time stamp | Smart | Yes | Naive | Incorrect UTC time stamp | Smart | Yes | Smart | Correct UTC Accurate elapsed time | - | Yes | Naive | Incorrect Accurate elapsed time | - | Yes | Smart | Correct UTC Naive - The conversion is unaware of leap seconds. Smart - The conversion is aware of leap seconds. Accurate Time Var - The values in the time variable have no unexpected internal or external offsets due to leap seconds. The last two entries in the table are, in truth, equivalent to the middle two. It doesn't really matter whether you started with UTC time stamps, TAI time stamps, or GPS elapsed time counts - as long as you end up with accurate TAI-compatible elapsed time values, the conversion to correct UTC time stamps must be smart (properly handle leap seconds). I'm open to other names for the two new calendars, but I think the suggested names are reasonable. -- 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/148#issuecomment-434048433
