On Thu, Mar 28, 2013 at 7:49 AM, Jim Biard <[email protected]> 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 [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
