Hi Aaron, As the last person to take a swing at this ISO 8601 piñata, I'm sorry to report it shows no sign of yielding candy. :-)
I don't have time to look up the correspondence, but the principal convincing arguments as I recall are (a) it is a simple value, not a string, thereby saving all sorts of space; (b) it is computationally minimal, often to create, and always to plot and find differences; (c) utilities make the time readily readable, and (d) it's the way we've always done it so there's a large pile of legacy data AND legacy software. Actually, it was a pretty compelling list of arguments. I can't remember exactly what I wanted -- I think the option to express time using 8601, maybe not the time coordinate but other time variables; nor what the exact conclusion was -- I think we could have string variables that have time in them, but maybe you couldn't declare them as standard_name = "time"? Someone else may be able to help out here. (Hmm, this should be a FAQ entry.) John G On Jun 26, 2015, at 10:37, Aaron Sweeney <[email protected]> wrote: > Hi, > > I have been following this thread with great interest and would like to > add my two cents. > > I work with data that is reported at 15-second intervals and, in the not > too distant future, am expecting to be working with data reported at 1-second > intervals. One of my goals is to find correlations, in the time domain, > among different observables, as measured by different data providers. It is > essential that we speak a common language when we talk about time. > > Having worked with different computer languages, I've realized they all > have a different internal representation of elapsed time (both level of > granularity and reference "zero") and different libraries to perform time > transformations and computations. I would pose the question: Is the > recording of an elapsed time within netCDF a requirement? > > Consider this alternative: For an observationalist/experimentalist, many > of today's data acquisition systems are synchronized with the Global > Positioning System, and, specifically, timestamps are assigned using UTC > (including leap seconds). I would argue the most interoperable form of these > timestamps is that defined by an ISO 8601 standard, and more tightly > constrained by the IETF RFC 3339 profile (e.g. "YYYY-MM-DDTHH:mm:ss.sssZ"). > In my mind, timestamps are simply labels that allow one to match up disparate > observations in the hopes of revealing cause and effect in the real world. > If data providers record ISO 8601 timestamps as strings in netCDF, then we > have some hope of avoiding the pitfalls of one provider transforming these to > elapsed times with leap seconds and another provider transforming to elapsed > times without leap seconds. Furthermore, if I am working with multiple data > sets created by different providers and I want to perform time computations > (difference, double-difference, etc.), I will use whatever library is > provided by my computer language of choice to transform from a time label to > an elapsed time, without having to worry about whether a data provider has > computed elapsed time in the same way as another provider. Essentially, I'm > doing that step myself. > > I realize many people are attached to the idea of elapsed time as a > fundamental coordinate, but I have never heard a strong argument in its favor. > > Thank you for your kind consideration. > > Cordially, > Aaron > > -- > Aaron D. Sweeney > Water Level Data Manager > > Cooperative Institute for Research in Environmental Sciences (CIRES) > University of Colorado at Boulder > and > NOAA National Centers for Environmental Information > (formerly NOAA's National Geophysical Data Center) > 325 Broadway, E/GC3 > Boulder, CO 80305-3328 > > Phone: 303-497-4797, Fax: 303-497-6513 > > DISCLAIMER: The contents of this message are mine personally and do not > necessarily reflect any position of NOAA. > > _______________________________________________ > 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
