@JimBiardCics wrote: > I'm calling the UTC time 'non-metric' because a time variable for data > sampled at a fixed rate based on UTC time stamps converted to elapsed time > since an epoch without dealing with leap seconds may contain deviations from > what you would expect. If you attempt to 'do math' with the contents, you may > find that adding an interval to a time does not produce the time you expected > and subtracting two times does not produce the interval expected.
Thanks, got it. My take on this -- if you do that, you have created invalid, incorrect data. CF should not encode this as a valid thing to do. As far as I'm concerned, it's the same as if you did datetime math with a broken library that didn't do leapyears correctly. And frankly, I'm not sure HOW we could accommodate it anyway -- I'm still a bit confused about exactly when leap seconds are applied to what (that is, I think *nix systems, for instance, will set the current time with leap seconds -- so the "UTC" timestamp is really "TIA as of the last time it was reset". Which I think is the concern here -- if you are collecting data, and are getting a timestamp from a machine, you don't really know which leap-seconds have been applied. But again, that's broken data.... If we were to try to accommodate this kind of broken data, I have no idea how one would do it? One of the reasons that leap seconds are not used in most time libraries is that they are not predictable. So a lib released last year may compute a different result than one released today -- how could we even encode that in CF?!?! -- 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-434395345
