Dear CF experts, Can I chip in here, without having read all of the back story, please?
I am busy with producing an OGC Best Practice for handling Time with geospatial data. One of the fundamental problems is that international standards bodies have produced inconsistent standards. E.g. ISO8601 defines a notation that uses the Gregorian calendar, with leap seconds; IETF specifies an RFC for timestamps on the Internet according to ISO8601 ECMA specifies standard JavaScript to use ISO8601 but specifies explicitly 'ignore leap seconds' And, of course, GPS time is tied to TAI, Atomic time, not the Gregorian calendar. One problem is that people are using ISO8601 incorrectly, either knowingly or from ignorance, therefore need another label/attribute to state this. Another problem is using coordinates and calendars interchangeably, when they are not. The OGC, for example, hosts a registry of defined temporal coordinate systems, but it does not have registry of calendar definitions. The BIPM and IERS in Paris do not seem interested in registries and variations of definitions. HTH, Chris Chris Little Chair, OGC Temporal Domain Working Group Co-Chair, OGC Meteorology & Oceanography Domain Working Group IT Fellow - Operational Infrastructures Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom Tel: +44(0)1392 886278 Fax: +44(0)1392 885681 Mobile: +44(0)7753 880514 E-mail: chris.lit...@metoffice.gov.uk http://www.metoffice.gov.uk I am normally at work Tuesday, Wednesday and Thursday each week -----Original Message----- From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of cf-metadata-requ...@cgd.ucar.edu Sent: Tuesday, April 28, 2015 4:35 PM To: cf-metadata@cgd.ucar.edu Subject: CF-metadata Digest, Vol 144, Issue 14 Send CF-metadata mailing list submissions to cf-metadata@cgd.ucar.edu To subscribe or unsubscribe via the World Wide Web, visit http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata or, via email, send a message with subject or body 'help' to cf-metadata-requ...@cgd.ucar.edu You can reach the person managing the list at cf-metadata-ow...@cgd.ucar.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of CF-metadata digest..." Today's Topics: 1. How to define time coordinate in GPS? (Jonathan Gregory) 2. Re: How to define time coordinate in GPS? (Jim Biard) ---------------------------------------------------------------------- Message: 1 Date: Mon, 27 Apr 2015 18:07:39 +0100 From: Jonathan Gregory <j.m.greg...@reading.ac.uk> To: cf-metadata@cgd.ucar.edu Subject: [CF-metadata] How to define time coordinate in GPS? Message-ID: <20150427170739.ga7...@met.reading.ac.uk> Content-Type: text/plain; charset=us-ascii Dear Jim > I don't think calendars are the right place to encode this. We could > add a new "time_system" attribute where you would declare whether your > time stamps and elapsed times were based on UTC, GPS, TAI, etc. > If we take this route, we should require the elapsed times to encode > leap seconds if the time system is UTC, and state that the default > time system is UTC. I think this is a calendar issue because the calendar is the set of rules which translate between components of time (YMDhms) and elapsed time (in fixed time units) since the reference time. Your later email seems to me to be consistent with that. In the real world, the elapsed interval (expressed e.g. as the number of seconds) between the ref YMDhms and the actual YMDhs depends on whether your calendar includes leap seconds (UTC) or not (GPS). It seems that GPS is the calendar likely to have been assumed in existing CF datasets, so it would be logical to say that the default is the real- world calendar without leap seconds. Have I misunderstood something? If we regard this as a property of the calendar, we don't need a new attribute. Best wishes Jonathan ------------------------------ Message: 2 Date: Tue, 28 Apr 2015 11:35:16 -0400 From: Jim Biard <jbi...@cicsnc.org> To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] How to define time coordinate in GPS? Message-ID: <553fa8b4.8000...@cicsnc.org> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Jonathan, I see where you are coming from, and there's validity in that line of thought. Leap seconds represent a finer-grained adjustment to the overall date/time system being used. I still think it makes good sense to add a new attribute to declare whether or not leap second handling was used or strengthen our standards for time variables so that problems are averted. From a human understandability perspective, a calendar attribute of "GPS" or "UTC" will be somewhat confusing. In my experience, people don't speak of the UTC calendar, it's UTC time. Further, TAI and GPS time don't really concern themselves with anything but counts of seconds since an epoch date & time. People convert the counts to time stamps for convenience, but they are actually more equivalent to the Julian Day Number (JDN) than they are to the Gregorian or Julian calendar. TAI and GPS time have different epochs, and TAI is more accurate, but they both are running counts of seconds that aren't tied to the motions of the Earth. As a result, I think that it's improper to talk about a GPS calendar or TAI calendar. What is being exposed by this discussion is the reality that any of us (myself included) have often ignored or been unaware of the fact that the time calculators (time handling software) we used when filling our time variables with elapsed times weren't giving us true counts of seconds since the epochs we wrote into our units attributes. If you are working at a resolution of days or hours, this will probably never cause a problem. If you are working at a resolution of minutes or less and working over a time span of greater than two years, it may well have caused at least occasional small problems. If you are working with full-resolution polar-orbiting satellite data, one second represents ~7 km of satellite motion, so such errors can produce significant geolocation errors. A set of elapsed seconds since a Gregorian/UTC epoch that were calculated from Gregorian/UTC time stamps without regard for leap seconds and which crossed a leap second boundary are not "GPS" seconds. Nor are they "UTC" seconds. They are, strictly speaking, elapsed times into which one or more step errors have been introduced. As I mentioned in a previous email, as long as you use the same time calculator to extract time stamps as you did to get elapsed times from input time stamps, you won't notice anything. You may notice a problem if you are taking differences between elapsed times and a leap second boundary gets involved. As I've considered all of this more, I'm tending to favor the second option I suggested. We could also be more strict, and say the epoch time stamp in the units attribute must always be in UTC. The question would then be reduced to whether or not leap seconds were counted into the elapsed times stored in the time variable. In this case, we could add a "leap_seconds" attribute which would have a value of "UTC" if UTC leap seconds were counted into the elapsed times, and "none" if not. This would also allow for some other system of leap seconds to be used. (I don't know if there are others.) For backward compatibility, considering history, the default value for this attribute would probably be "UTC". Clearly, having epoch time stamps with time zone offsets from UTC, as described in the CF conventions, would be OK as well. I'm also open to other namings for the new attribute and for its possible values. The leap seconds only become an issue in certain rather specific instances, so I think that such an attribute, along with a bit of discussion in the document, would likely be sufficient to warn those people that may find themselves negatively affected by improper leap second handling. Grace and peace, Jim On 4/27/15 1:07 PM, Jonathan Gregory wrote: > Dear Jim > >> I don't think calendars are the right place to encode this. We could >> add a new "time_system" attribute where you would declare whether >> your time stamps and elapsed times were based on UTC, GPS, TAI, etc. >> If we take this route, we should require the elapsed times to encode >> leap seconds if the time system is UTC, and state that the default >> time system is UTC. > I think this is a calendar issue because the calendar is the set of > rules which translate between components of time (YMDhms) and elapsed > time (in fixed time units) since the reference time. Your later email > seems to me to be consistent with that. In the real world, the elapsed > interval (expressed e.g. as the number of seconds) between the ref > YMDhms and the actual YMDhs depends on whether your calendar includes leap > seconds (UTC) or not (GPS). > It seems that GPS is the calendar likely to have been assumed in > existing CF datasets, so it would be logical to say that the default > is the real- world calendar without leap seconds. Have I misunderstood > something? If we regard this as a property of the calendar, we don't need a > new attribute. > > Best wishes > > Jonathan > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar* Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA?s National Climatic Data Center/ 151 Patton Ave, Asheville, NC 28801 e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org> o: +1 828 271 4900 /We will be updating our social media soon. Follow our current Facebook (NOAA National Climatic Data Center <https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA National Oceanographic Data Center <https://www.facebook.com/noaa.nodc>) and Twitter (@NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData <https://twitter.com/NOAAOceanData>) accounts for the latest information./ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150428/2f99a006/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: CicsLogoTiny.png Type: image/png Size: 15784 bytes Desc: not available URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150428/2f99a006/attachment.png> ------------------------------ Subject: Digest Footer _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata ------------------------------ End of CF-metadata Digest, Vol 144, Issue 14 ******************************************** _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
