Time has been weighing heavily on my mind as of late.
First there was a netcdfgroup discussion about various schemes for
representing time in a netCDF. Then, in responding to a question on
the planned suite of netCDF programs, I put my foot in my mouth
(letting the cat out of the bag) by saying that our current plan is to
use the "units" attribute together with a new "origin" attribute to
represent time.
I've since received a few ... err ... requests for additional information.
Allow me to take this opportunity to explain my current thoughts on the
matter of netCDF time.
The problems with time are these:
1. There is no origin (let us ignore the Big Bang, please!);
2. No single datatype can span the range of possible values with
arbitrary accuracy.
There was a posted exception to #2, namely measuring time in
milliseconds since the Epoch (Jan 1, 1970 at 0000 UTC). Unfortunately,
this can easily be inadequate outside its domain of application
(oceanography, if I remember correctly).
Thus, most posted solutions have proposed to measure time as an offset
(in some standard units) from an origin, which is either implicit or
specified using some convention.
Unfortunately, these, too, have the drawback of potentially limiting
domains application.
What I would like is a method for handling time that would
1. Allow generic routines to handle time variables without any
special considerations;
2. Allow the input and output of time values (e.g. via a CDL
file) in a convenient and intuitive manner.
Naturally, I have a proposal.
The Unidata UDUNITS library, which is used to manipulate units, can
already interpret the following CDL "units" attribute as a
specification of degrees Celsius:
foo:units = "1.8 degF @ 32";
This is interpreted as "units of 1.8 degrees Fahrenheit from an origin
of 32 degrees Fahrenheit".
Thus, I don't think it would be too difficult to enhance the UDUNITS
package to accept specifications such as the following:
time:units = "milliseconds @ (1992-2-11 12:53:45 -700)";
which would be milliseconds since the given date and time (the "-700"
specifies the Time Zone). This modification would allow programs to
convert from one unit of time to another quite automatically.
As I see it, this has the following advantages:
1. Generic programs using the UDUNITS package could handle time
just like any other variable;
2. The resolution could be chosen to fit the data (e.g.
"fortnights" for some long-term observational dataset);
3. The origin could be chosen to fit the data (e.g. "January 1,
1850" for historical data).
4. Input/output programs could handle time with no more effort
than usual (since they have to special-case time anyway);
5. No conventions are necessary, and the self-describing nature
of netCDF's is maintained (well, we have to agree on using
Western Calendar notations, but that's already an ISO
standard).
The only disadvantage that I see is the necessity for a date and time
parser. Fortunately, there is a freely-available one (from netnews or
GNU) that will handle just about any specification one can think of.
It also has no copyright.
Any and all comments on this proposal are most welcome.
Regards,
Steve Emmerson <steve@unidata.ucar.edu>