Dear all Although the rules say that there should be moderator, in most trac tickets we have not had one, because no-one has volunteered. I agree it would be good to have a moderator who understands the discussion but doesn't want to argue for a particular view. Whoever does it, summarising where we are from time to time is useful.
Since I have been arguing for particular choices in this discussion, I might not be taking proper account of the other views, but in case it helps, my summary of the position is this: * We agree that a new CF calendar is needed for real-world data that refers to UTC. In this calendar, the `units` string will contain a reference timestamp (YYYYMMDD HHMMSS) which is a valid UTC time, including leap seconds. When timestamps are converted to coordinates (i.e. time elapsed since the reference timestamp) and vice-versa, leap seconds must be allowed for i.e. there are some minutes of 61 seconds. The difference between two time coordinates gives the correct interval of time which elapsed in the real world between those UTC timestamps. * We agree that new CF calendars are needed for real-world data that refers to TAI or GPS time. In these calendars, the `units` string will contain a reference timestamp which is a valid TAI or GPS time respectively, in which there are no leap seconds. When timestamps are converted to coordinates and vice-versa, there are no leap seconds; all minutes have 60 seconds. The difference between two time coordinates gives the correct interval of time which elapsed in the real world between those timestamps. * The existing `gregorian` calendar is used for both real-world and model data. The conversion between timestamps and time coordinates for model data doesn't use leap seconds, and the difference between two time coordinates gives the correct interval of time which elapsed in the model world between those timestamps. * As far as I know, no-one disagrees with continuing to use `gregorian` for model data which uses the Gregorian calendar, with no leap seconds. * For real-world data in existing CF datasets with the `gregorian` calendar, it is ambiguous how the time coordinates have been computed. The real-world Gregorian calendar is understood to mean UTC by most people. Some data producers may have converted UTC timestamps to time coordinates taking account of leap seconds. It is likely that most data produces converted UTC timestamps to time coordinates without accounting for leap seconds. If such a coordinate is converted back to a timestamp, again without taking account of leap seconds and assuming all minutes have 60 seconds, you recover the original timestamp correctly (unless it had seconds=60). However, the difference between the coordinates computed in this way from two UTC timestamps is not the exact interval of time which elapsed in the real world between those UTC timestamps, if they span any leap seconds. * We agree that this ambiguity is undesirable. I think this encoding for UTC must continue to be allowed for real-world data, because it's widely used, convenient and accurate enough for most applications. If you do use a time interval as though it were exact, you'll only be wrong by a few seconds over several years. I believe Chris thinks it should be retained as well. I have argued that it should continue to be called `gregorian` for real-world data (as well as model data), but probably Chris and Jim think it should be called something else, to make clear that (unlike in the model case) it doesn't always give correct time intervals. It may also have been argued that we should have a name for a calendar which represents UTC timestamps but it is not defined whether they were converted to coordinates with leap seconds or not. I don't think we should allow such a deliberately ambiguous case (even though the existing `gregorian` is ambiguous in that way). I hope that helps. Happy weekend, everyone. Jonathan -- 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-437393242
