On 3/15/11 12:18 PM, John Caron wrote:
>> I'd propose that a good way of thinking about the distinction between
>> dates and times is that "time" is a geospatial unit of measure ,
>> whereas "date" (which includes "time of day") is a way of formatting
>> time units for human readability.
Hmm. the time libs I've used use the term "datetime" to mean a
particular instance:
Jan 5th, 2011, 12:45:20
(in a defined calendar)
Then they use the term "timedelta" to specify what really is a unit in time:
hours, seconds, milliseconds, etc. I don't think I've seen one that
expresses a timedelta in months or years.
>> ISO 8601 has standardized the formatting of dates, which is definitely
>> a good thing. But too often we are tempted to borrow this standard
>> into science a an encoding of time.
right -- ISO8601 is a representation of a "datetime" NOT a timedelta.
In a good lib, a timedelta is it's own thing -- ideally you don't even
know how it is being stored internally (*seconeds? milliseconds? who knows?)
So the CF standard of "time_units since date"
Can be though of as "timedelta" since datetime.
So what are reasonable units to express timedeltas in?
I think the point here is that "months" or "years" is simply not
appropriate for that, period.
It can be usefull to express monthly averages, and the like -- it does
help with our ordinary way of expressing and thinking about time,
season, etc, but in that case I wouldn't have data stored as:
months since Jan, 1960.
I'd rather have it labeled:
January
February
March
etc....
as it's really a category, rather than a value.
> a calendar date/time (Feb 23, 1999 13:33 Z) is a representation of an
> instance of time which is human readable, and therefore less prone to
> errors because it can be easily noticed. So that representation has
> advantages over something that requires software to interpret.
That is a fine way to express some things, and in common use. A lot of
meteorological and oceanographic data is expressed that way, with a
datetime stamp and the value, but it's not expressed as "months since"
The "hours since...' representation is a convience for storing and
workign with timeseries of data on a computer. Either way, you can
either convert to make things human-readable, or convert to make it easy
to work with on a computer.
I've lost track a bit about what is being considered here:
1) Is anyone proposing that "months since.." and "years since..." is a
good way to express a time series? I would personal say not.
2) Sorry for my CF-ignorance, but is it currently accepted to express
the time axis as an array of ISO date strings? If so, I think that's
fine for some uses, anyway, but it should be used judiciously.
As for libs, the Python NetCDF4 lib (Thanks, Jeff Whitaker) provides
converters to/from "time_units since" from/to python datetime objects --
this is very handy, indeed, and probably should be built into the C and
Java libs, though I don't know if there is any standard for a datetime
object in C or Java.
I suppose we could propose a binary representation for datetime and
timedelta objects to be used in netcdf -- but is it worth the effort?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
Received on Tue Mar 15 2011 - 15:59:02 GMT
