Dear Jim > I think, too, that gregorian_nls shouldn't be taken to imply that UTC was > ever used. In fact, if we keep gregorian, I think that there is no need for > gregorian_nls. My suggestion for a working definition for gregorian_nls was > > "Reference timestamp expressed in Gregorian calendar with generic time > system having 86400 seconds per day based at longitude 0 degrees. There is > no exact conversion available between this and other calendars."
So we haven't quite agreed after all :-). I expect there are data-producers who would like to record UTC times, but they know their software doesn't take account of leap seconds. In encoding without leap seconds, they are pretending that the real world is not quite what it is, for convenience. By doing so they make the elapsed times sometimes slightly inaccurate, but by declaring what they have done they make it possible to recover exactly the UTC timestamps they had to begin with. That seems advantageous to me. Hence I think we should offer the possibility to say explicitly that this is what has been done. A use-case could be a weather forecast model, or a climate model which is being used for a hindcast or a prediction from observed conditions. These models would use real-world UTC times for their real-world data, but very likely would not have leap seconds in their calendars, because weather forecasts and climate predictions do not have precision to the second. It seems less good to me that this case should not be distinguishable from the case where the data-producer chooses not to specify whether the time is UTC or GPS or the encoding. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
