@larsbarring Here's my thoughts on your questions. 1. The satellite community needs highly accurate time for two related reasons. The discussion that follows is most relevant for satellite swath data. This is data from along the satellite track that hasn't been aggregated into global maps. The absolute location of a polar-orbiting satellite (which I am most familiar with) at any given time is often referenced by the elapsed time since launch or some other epoch (such as the TAI epoch). This time often functions as a unique label for a granule of data. During processing the time is first used to choose a satellite state vector from a list and then determining the location using the time elapsed since the epoch time of the state vector. Given the ~7 km/sec speed of such satellites, an error of a single second can produce a significant geolocation error that may amount to many pixels. For these reasons, and in the interest of preserving original information if further processing or reprocessing is needed, satellite data producers have a strong interest in preserving the elapsed times. They want to be able to tell their users that the elapsed times in the time variables are precise and accurate, with no jumps or offsets. 1. We need to make sure that nothing we are doing here causes any problems for the modeling community. I think that the somewhat different issues facing them, and the larger community when data is aggregated on months, seasons, or years, are best addressed in a different topic. 1. I personally think that the current **`gregorian`** calendar is sufficiently well defined and doesn't cause problems. The **`gregorian + extension`** form, assuming we use it, is providing further guidance for users on specifics on how to handle the contents to get accurate time stamps. I'm open to other names.
-- 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-435951382
