Reference: Posting I made on 5 February 1992, 15:09:23 EST
It seems that the netCDF mailgroup aperiodically has discussions about
storing time information. Hence, I repost my earlier comments with regard to
CDF and netCDF and storing time. From an applications perspective, I should
note that when Data Explorer imports a CDF with the optional reserved variable,
EPOCH, in CDF, which is typically mapped to the record dimension in CDF (i.e.,
equivalent to the unlimited dimension in netCDF), the values are used to
define a "position" for each member of the imported time series. For a netCDF
the unlimited dimension is mapped to members of a time series as the record
dimension would be for a CDF. Let me ask Russ, Steve et al and netCDF users,
assuming relevance herein, if a similar optional "reserved" variable were
established for a netCDF variable containing time information, Data Explorer
could then assign a position or time stamp for each member of a time series.
Currently, that information is enumerated from the index along the unlimited
dimension. Comments?
Lloyd Treinish
------------------ Note from 5 February 1992, 15:09:23 EST--------------------
As that great sage, Yogi Berra, once said, "it's deja vu all over again"...
This most recent discussion parallels deliberations over conventions to drive
CDF applications at NASA/GSFC that took place over 6 years ago. I did post
some comments about this to the netCDF group on 10/30/90 (attached below).
Epoch-based time as a double (for ms) and calenderic utilities are part of the
CDF distribution (for both portable -IEEE- and native encoding). This was
decided back then for the same and additional reasons that others have
outlined yesterday and today. CDF-based visualization tools certainly
take advantage of the precision and flexiblity of this approach. But it's
not required. When it is used it can be mapped to a specific dimension.
Applications can break up the double for separate (dimension-like) manipulation
of time in more convenient chunks (e.g., year, hours, etc.) especially in
making plots to match display and data resolution.
Lloyd Treinish
------------------- stuff from 10/30/90 posting ------------------------------
As just a point of information, CDF Version 1 (as well as subsequent versions)
at NASA/GSFC-NSSDC has NO specific requirements or conventions for time. There
are specific CDF-based data analysis and visualization applications at NSSDC
that require a time convention for specific temporal manipulation utilities.
That convention is the one that Russ referenced. The specific choice of
"units" was based on the need to support historical data as well as space-borne
observations with a single "absolute" epoch reference. Nothing in CDF or
netCDF precludes the use of other time conventions. Many time-dependent data
sets have been created in CDF without the msec since 0 AD convention, or with
an additional temporal variable (e.g., a running time such as "time since
launch"). CDF as well as the NSSDC CDF utilities can handle those alternate
forms for time. It's just that there are specific utilities for that time
representation, which are optional for a user. I hope that clarifies the
point. I certainly have a number of ideas on time representation based
upon applications or storage form, which netCDF can easily support. But Russ'
approach is fine from the netCDF perspective. Specific netCDF-based software
may require something less flexible, but that's an exercise left up to the
netCDF user.
