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
