Dear Jim, Chris et al. I'm using the word "calendar" in a CF-consistent way, I believe. Maybe it's not the best word for the concept, but nonetheless we have an attribute called "calendar", and its sole function is indicate which algorithm is used to translate between components of time (YMDhms) and elapsed time (in units of time since a reference time). So perhaps that is consistent with "calendar" being a collection of algorithms, in Chris's text, but it's more specific than that. It has a particular function in the interpretation of CF time values (usually coordinates). CF sect 4.4.1 says "In order to calculate a new date and time given a base date, base time and a time increment one must know what calendar to use." and I think that is the sense in which I am using "calendar".
> In the "real" world, we often start with UTC timestamps that have > leap seconds accounted for, yet convert them to elapsed times using > calculators that don't account for leap seconds. This can actually > lead to elapsed time values that encode a time discontinuity and > cannot be counted on to produce accurate differences between every > pair of values. This is a problem, I agree. We should avoid that problem for future data by making the conventions more precise about which calculator should be used (which calendar, in the CF sense). We can't decide for sure what was done when encoding past data, but the conventions string records the version of CF used. > I'm suggesting that we need to do two things. One is to more precisely > define what sorts of times can be used in the time reference part of > the units attribute. I just reread section 4.4, and it actually says > that the time is UTC or a time zone offset from it. I think it > should stay that way and the wording strengthened to make it > clearer. Yes, it does say that. It's a quote from the udunits man page. However I don't think the issue of leap seconds has been carefully considered before, so we don't have to assume that's what it meant exactly, especially as udunits does not support lead seconds. As previously said, and I think you may agree, it is likely that nearly all existing time values have been encoded *without* leap seconds, and therefore *not* UTC strictly. Therefore my alternative suggestion is that we should add some text here that says we don't necessarily imply leap seconds are included by mentioning UTC. This must be the case, because the same format of time unit is used for calendars that definitely do not ever include leap seconds i.e. all the non-real-world ones. UTC is mentioned simply as a way to refer to the time-zone which contains the Greenwich meridian, without summer time. > The other thing I think we need to do is provide a way to indicate > that the elapsed times in a time variable are true elapsed times > that are certain to be free of leap second discontinuities, or are > possibly contaminated with leap second discontinuities. In > connection with this we would need to add clarifying language in the > CF conventions to educate people on the importance of using time > calculators that are aware of leap seconds when moving between UTC > timestamps and elapsed time values. This could be handled by adding > a modifier to a calendar name in the calendar attribute, or it could > be handled by adding a new attribute to hold this information. I > think that coming up with one or more new calendar names is a more > confusing and less useful way to accomplish this. I don't think we should define a new attribute, because this distinction is one which applies only to the real-world calendar. It's therefore more robust and simpler to indicate it as a modifier to the name when applicable in the the calendar att, so making a new calendar name, in effect. But given this discussion I agree that calling it just "UTC" may not be clear enough. The real-world calendar is called "standard" or "gregorian". I would propose a new possibility "proleptic_gregorian_utc", meaning the proleptic Gregorian calendar with leap seconds inserted as applicable since 1958. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
