Hi all, OK, I had four replies to my email concerning ISO8601 time strings and precision so I'm going to respond briefly to them all simultaneously, without the aid of a safety net. I hope I'm capturing the important points:
1. Steve and Roy both asked (I think) why we can't have a more general notion of precision that applies to all coordinate axes, not just time. I argue that precision in time *can be* (but is not always) different semantically. When I say "these data are representative of June 2009" I don't mean "these data were collected on the 15th of June 2009, plus or minus 15 days". The concept of "data representative of a time period" is very different from "data collected at an uncertain time". "Representative" data is commonly found in high-level analysed products, not so much in instrument records I guess. 2. Also (still replying to Steve), there's nothing to stop me interpreting "100.0" and "100.00" as exactly the same value - there's no *explicit* precision, although a human *might* infer one. (Anyway, when numbers are represented as binary there's no way of telling the difference.) In ISO8601, the truncation is defined to imply precision (I think). 3. Nan said: "...there's nothing to prevent us from indicating lower resolution by using "minutes since" or "hours since" instead...". There's nothing in the CF conventions that says that "minutes since" implies a precision of minutes, *although perhaps it could* (a topic for a proposal?). AFAIK, "60.0 seconds since X" is currently treated by the conventions as exactly the same as "1.0 minute since X". But what if the actual precision is nanoseconds? An axis defined as "y nanoseconds since x" would have some pretty big numbers, maybe that's not a problem. I can see another couple of disadvantages to using ISO8601 strings though: i. UDUNITS strings are not ISO8601 strings, although they are close. Would it be confusing to have two different syntaxes for specifying time? ii. ISO8601 strings are defined to be in the Gregorian calendar (although it could be sensible to relax this assumption and just take the string to indicate year/month/day etc in a specified calendar, as long as the new calendar has the same concepts of fields.) Jon -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Graybeal Sent: 20 October 2010 20:00 To: John Caron Cc: [email protected] Subject: Re: [CF-metadata] New standard names for satellite obs data Count me in the group of people who are sorry you lost your bid to include ISO-8601 time strings, John. I have voted on the ISO 8601 side myself (although as I recall, more in the spirit of representing multiple times in a single file). I understand it raises complexity considerably to allow ISO-8601 formatted time in place of the regular format of the udunits time. So I can accept not going down that path. With John C's note that this would merely permit the addition of ISO-8601 variables, not the replacement of the standard coordinate, I fail to see how it would be a bad thing. It really is a common data representation and content, for which there is currently no acceptable standard name. Under these conditions, is there a specific bad practice being violated? Here are the advantages of this option as I see them: 1) Readability in native form without conversion. Understandably not a high priority for a binary standard like netCDF, but for auxiliary variables (not the time coordinate) this is a non-trivial benefit. 2) User chooses appropriate resolution, which is unambiguous. My ISO 8601 timestamp can be YYYYMMDD, YYYYMMDDThhmmss, or many other variations of these, according to my own data set. If I have mixed data in one netCDF file, I can even represent different resolutions within the same file. I am not aware of any equivalent way to represent time precision in netCDF. 3) It can represent date, time, or a combination thereof. It might be argued this is a negative due to the lack of a priori certainty (which kind of value is represented here?). If this is a problem, it can be resolved via slightly finer standard_name selection (e.g., datetime_iso8601 vs timecode_iso8601) 4) It can include rich time zone information. Often this is relevant in time data (that is, timestamps) collected from sensors or computer systems. 5) It gives me a standard_name for storing a quite common encoding of data values (considering time as a data value, which it often is) without transformation. By allocating the max length, all smaller ISO 8601 strings can be accommodated. (Note: because "There is no limit on the number of decimal places for the decimal fraction", I'm not sure there is an a priori limit on all ISO 8601 strings -- this would have to be set in the variable definition for the file.) ISO 8601 definitely a string format, mixing encoding format and concept name in the same standard_name. In CF, perhaps that itself is a bad practice. But it is such a commonly used standard for a data value, I wonder if the practice is worth allowing in this case? Or if not, then supporting the use of ISO 8601 via some other, automatically detectable alternative? John On Oct 20, 2010, at 05:35, John Caron wrote: > On 10/19/2010 12:55 PM, Mike Grant wrote: >> On 19/10/10 14:21, Aleksandar Jelenak wrote: >>> Actually, I don't think it is possible to use 'time' standard name in >>> such cases. If I correctly interpret CF rules for using standard names, >>> 'time' data can be only in the physically-equivalent units to "seconds". >>> Strings, being dimensionless, do not qualify. >> >> Out of curiosity, why do you want to store time as strings? It's easy >> to create those strings from numerical values, and numerical values are >> easier to handle in code (and in netcdf-3, as Seth said). >> >> Cheers, >> >> Mike. > > I made a proposal a few years ago to allow ISO-8601 time strings to be an allowable form of time coordinates, which was not accepted. I would be interested to hear what your reasons are to use this form vs udunits (eg "secs since reference")? ISO-8601 time strings are fixed length (21 I think?) so handling in netcdf-3 is not so hard. > > Your proposal would amount to standardizing how to include ISO-8601 time strings, but the standard udunits time coordinate would still be required. > > Clarification of your purpose might clarify the name. At first glance, I might prefer "time_iso8601" over "time_label_iso8601". > > John > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal <mailto:[email protected]> phone: 858-534-2162 System Development Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
