On Thu, Mar 28, 2013 at 7:49 AM, Jim Biard <jim.biard at noaa.gov> wrote:
> It seems to me that we are trying to figure out how to denote that a
> variable contains a "non-arithmetic" expression of time, similar to "degree
> minute second hemisphere" representations of latitude and longitude.
> (Non-arithmetic may be a poor way of expressing what I mean. I'm trying to
> say that you can't just take two values and add or subtract them in an
> atomic operation.)
sure you can -- in both cases. you can't add or subtract the strings
directly, but neither can you add or subtract anything with a computer
without specifying an encoding and the operations on that encoding. It
just so happens that any system we care about has basic integer and
floating point types, and most don't have a datetime type, but that's
an implementation issue.
> You can represent such values in strings, but you can
> also represent them by packing them into long integers (to millisecond
> accuracy).
exactly -- these are different encodings of the same information.
> I see no reason to exclude the use of the units attribute to denote that the
> values are expressions of time in which the time since the epoch has been
> diced up into years, months, days, hours, minutes, and seconds (with varying
> precision indicated by omission of finer resolution elements). Our current
> use of the units attribute for time does more than just specify the units
> (days vs hours, etc). What are the units for such a non-arithmetic time
> value? They are complex. We could specify something like "years months
> days" (in the case of a variable that contained dates only), or we could
> specify something like "datetime". When you went to the units table to find
> out datetime means, you would find a description.
I had argued that this wasn't a unit -- and indeed, I don't think it
is, but the current CF convention is to use "time_unit since datetime"
as the unit, which is more than a unit as well. So it wouldn't be
inconsistent to allow a unit like "iso8601 string".
However, that means specifying an alternate way to encode datetimes in
CF, which I don't think we should do.
If you have ISO strings associated with your data that you want to
preserve, and want to be reasonably human readable, there is no reason
you can't put them in a string variable, with a long_name that
describes what it is. If it's not going to be used as the time
coordinate, then we don't need a standard_name or unit for it, as you
don't need libraries to be able to universally auto-detect it and be
able to compute with it.
-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 Thu Mar 28 2013 - 14:23:37 GMT
