Dear Jim and Karl Thanks for your emails.
To Jim, I think I spoke too soon! I do agree that it's better to be precise, but I'm concerned on reflection that there are two uses of real-world time encoded as if there were no leap seconds in the real world: * Observational data or models run with observational input, where the data is timestamped in UTC, but encoded as coordinates without leap seconds. This is what we agreed to call gregorian_utc_nls. In this case we pretend that the real world has a constant day-length and no leap seconds. * Models run to resemble the real world, with the real-world calendar and the intention to compare actual weather or climate with model output, but without leap seconds. CMIP5 historical and AMIP experiments are in this category, for which some models use the real-world calendar (but no leap seconds), and some of the input (for instance SSTs and atmospheric composition) refers to the real-world calendar. However it is model data, and the model definitely does not have leap seconds, so cannot truly be UTC at all. It actually is running with a constant day-length. Thus we can't rightly call this gregorian_utc_nls. It would be more accurate to call it gregorian_nls (not UTC, not GPS). However the distinction between gregorian_utc_nls and gregorian_nls is very subtle. I can barely see it myself, even when writing about it! I expect it would not reliably be made by data-producers. Therefore I'd like to revert to gregorian_nls for both cases. I think this only applies to UTC really. GPS does not have leap seconds anyway, so a special no-leap-second encoding would only be needed if you put a reference time for GPS before the GPS epoch. Maybe we should disallow that, to avoid this ambiguity. Therefore, with apologies, I have to ask the opposite question of whether you could live with gregorian_nls to mean encoded UTC when it's truly real-world data. I don't think it's satisfactory to call it just "gregorian" because we have also recognised the need for a deliberately imprecise situation, when it's not known if it's GPS or UTC or how encoded. gregorian_nls is precisely 86400- second days, encoded as such, by intention. Karl, do you have any comments about this? Karl, I agree with your analysis. Jim and I also discussed ways of changing the calendar, and we decided it wasn't essential to the definitions as such to say how you could do it. Another possibility for changing from UTC to GPS or v-v is to alter the reference time and its calendar so it refers to the same instant in the real world. Then you don't need to alter the encoded time coords. For changing between real-world and model calendars, I would argue that they are only related via timestamps in principle (that is, January is the same in both sorts of calendar only because it's regarded as January and comparable for that reason), and the simplest way to convert is to decode the coords to timestamps in the old calendar and reencode in the new calendar. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
