@ChrisBarker-NOAA @JonathanGregory I'm good with doing a write-up in the form of a pull request, but I felt it was important to get people on somewhat the same page before doing so. Here's a quick restatement of what I am proposing, with some alternate names for the new calendars.
- **`gregorian_metric`** This calendar is used to indicate to users that the elapsed times contained in the variable are fully metric - that is, there are no unexpected non-linearities or offsets, and math operations such as difference between values, addition of an offset, division by an interval, etc will produce valid results. It also indicates that the epoch date and time in the **`units`** attribute on the time variable is a precise and accurate UTC time stamp. Conversion of the elapsed time values in the variable to precise and accurate UTC time stamps will require the use of a leap-seconds table if one or more leap seconds occurred between the epoch date and time and the date and time corresponding to the elapsed time value. - **`gregorian_nonmetric`** This calendar is used to indicate to users that the elapsed times contained in the variable may not be fully metric - that is, there may be unexpected non-linearities or offsets, and math operations such as difference between values, addition of an offset, division by an interval, etc may not produce valid results. It also indicates that the epoch date and time in the **`units`** attribute on the time variable is a precise and accurate UTC time stamp. This calendar also indicates that these possibly non-metric elapsed time values were produced in a very specific way. The elapsed times were produced by conversion of precise and accurate UTC date and time stamps to elapsed times since the **`units`** attribute epoch date and time stamp without accounting for leap seconds. Any lack of metricity is due only to the lack of consideration of leap seconds that were added or subtracted between the **`units`** attribute epoch date and time and the dates and times corresponding to the elapsed time values. The elapsed time values in the variable may be converted back to precise and accurate UTC time stamps using the inverse of the production conversion, again without accounting for leap seconds. If the user wishes to obtain fully metric elapsed times from the contents of the variable, it is possible to do so using a leap seconds table and analyzing the time series to determine the points at which leap seconds may need to be added or subtracted in order to correct any offsets or non-linearities. **`Warning`** For sufficiently fine time resolution (<= 1 second), it is possible that a variable using this calendar may be non-monotonic if the span of the elapsed times includes instances when one or more leap seconds were added. (This is an admitted violation of the CF conventions regarding coordinate variables, but the case is limited in scope, has a well-understood cause, and has a straightforward workaround. The large class of data producers and users already successfully using time variables in just this way argues in favor of explicitly allowing this calendar.) - **`gregorian`** This calendar is used to indicate to users that the elapsed times contained in the variable may not be fully metric - that is, there may be unexpected non-linearities or offsets, and math operations such as difference between values, addition of an offset, division by an interval, etc may be not produce valid results. It also indicates that the epoch date and time in the **`units`** attribute on the time variable may not be a precise and accurate UTC time stamp. The accuracy of time stamps derived from the elapsed time values in the variable are not guaranteed to better than 37 seconds (as of 2018) because it not known how leap seconds have been handled during production of the elapsed time values. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435968217
