@ChrisBarker-NOAA The first idea here is to allow data producers a way to clearly indicate that the values in their time variables are metric elapsed time with none of the unexpected discrepancies that I referred to earlier. Instead of **`gregorian_tia`**, we could call the calendar **`gregorian_linear`** or **`gregorian_metric`** or some such. We thought to reference TIA because TIA is, at base, a metric, linear count of elapsed seconds since the TIA epoch date/time.
The second idea here is to allow data producers to clearly indicate that the values in their time variables are non-metric elapsed time potentially containing one or more of the unexpected discrepancies that I referred to earlier, and to indicate that in all but one case they will get correct UTC time stamps if they convert the time values to time stamps using a method that is unaware of leap seconds. This result is not guaranteed if you add an offset to a time value before conversion, and differences between time values may not produce correct results. You may obtain one or more incorrect time stamps if your time values fall in a leap second. Keep in mind that the potential errors are, as of today, going to be less than or equal to 37 seconds, with many of them being on the order of 1-2 seconds. For backward compatibility, and for the vast number of datasets out there where errors of this magnitude are ignorable, the existing **`gregorian`** calendar (with a warning added in the Conventions section) will remain. It would impose a pretty severe burden to insist that all data producers use only **`gregorian_tai`** or **`gregorian_utc`** going forward. The use of the word **metric** is problematic because minds inevitably go to **metric system**. I have used it this way so many times when thinking about this that I forget that is is confusing. -- 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-434434805
