Hello All, I accept @ChrisBarker-NOAA that my objection to the solution @JimBiardCics has called `gregorian_utc` is pedantic, but I still consider it important. My objection has nothing to do with the name, but is to do with the fact that an increment of 1 second in the time variable may be interpreted as 2 seconds. This is fine in a an index, but not in a variable with standard name `time`. More on this below.
The alternative suggested by @ChrisBarker-NOAA above, of providing support in CF for time stamps to be stored without forcing the user to go through error-prone translations looks preferable to me, and far more robust. Ideally, they should be able to store not only the time stamp information but also some information about where it came from. Coming back to whether a one second adjustment to time coordinates matters. As I said, I'm being pedantic without apology. We all know that information put in files contains many uncertainties, and errors in time information greater that a second are certainly common. The issue here is about the precision and robustness of the standard. In the example described by @JimBiardCics [above](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435181134) , a variable of variable value of `39` should, according to the proposed convention, be interpreted as `40` on the assumption that a user who is unable to process the time stamp accurately has reliably provided the full information about the method he is using to process the time stamp. I think this well known and perhaps overused comic from [xkcd](https://xkcd.com/927/) sums it up: there are two many standards for dealing with leap seconds ... adding another one looks like adding more confusion to me. I'm not convinced that "UTC converted to elapsed time without taking leap seconds into account" can reliably handled in this way. If the consequences of the neglect of leap seconds are predictable, everything is fine, but software is seldom that reliable. There may also be issues around the data being stored. The user who is providing the data may integrating or differentiating the data, making use of his/her time increment which, according to the proposed standard would be different from the time increment seen by applications which apply the leap-second adjustment. As pointed out in a comment by Chris [above](https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435152076) it is not that hard to find a library to deal with leap seconds. It may be worth trying to get such support incorporated into cf-python and making the community more aware of the issue by updating the convention to allow users to choose between fixed length days (i.e. TAI) or (UTC). -- 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-435464856
