@ChrisBarker-NOAA <https://github.com/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.
*gregorian_tia is fine.* 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, OK, I vote to simply not allow that in CF. Those discrepancies are errors. If second level precision is important, then don’t use a library without that precision to write your data. 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. I’m not sure we can know that for a given dataset. As leap seconds are unpredictable, and computer clocks imprecise, the “UTC” time you get from a system clock may or may not have had the last leap second adjustment at just the right time. Granted, that’s only a potential second off, but still ... If your application cares about second-level precision you should use TAI time — isn’t that what GPSs use, for instance? So in a CF time variable with, e.g. seconds since a_datetime_stamp The only thing you should need to know is whether the time stamp is UTC or TAI. Other than that, a second is a second.... In practice, if you care about second-level precision, you really should use a time stamp that’s close to your data anyway :-) 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. Agreed. The use of the word *metric* is problematic Well, I think I got that part anyway :-) -CHB -- 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-434512870
