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 <aaron.sweeney at noaa.gov> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Sat Jun 27 2015 - 23:22:57 BST
