On 3/27/2013 8:56 AM, Chris Barker - NOAA Federal wrote:
> On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin <steven.c.hankin at noaa.gov> wrote:
>
>> ISO date-time strings are a way of encoding the physical quantity
>> that we know as TIME. So TIME is the "right" standard_name for ISO
>> date-time strings per the definition quoted above.
>>
>> Now, it may be that there is a compelling argument to violating the normal
>> definition of standard_name for the case of ISO date-time strings. Or on
>> the other hand is it preferable to use the units attribute to indicate the
>> use of an ISO date-time string?
> An ISO string for a datetime is not a name (it's still time), but it
> is not a unit either.
>
> What it is is a data type -- more akin to a float or integer -- i.e. a
> particular way to translate bytes to a value. The bytes are a char
> array, and the value is the datetime itself.
>
> I don't know if thinking about it this way is helpful, as we are
> building on netcdf, and I don't now that netcdf allows you to define
> new data types, but food for thought.
Hi Chris,
Spot on. It is indeed food for thought. Here's an analogy for what is
being proposed. Suppose we proposed that CF should permit longitudes to
be encoded as a special string type that displayed degrees, minutes and
seconds in a friendly human-readable way. For example,
"130Edeg 22min 15sec"
This encoding shares the essential characteristics of proposed ISO
date-time strings
1. it has no definable units
2. it is not "computable" unless a library is found that can handle it
3. it adds no encoding capabilities to what CF already has
How would we evaluate this proposal? What alternatives might we suggest
for the use cases in which longitudes were required to be in this encoding?
- Steve
>
> Also, of course, all the other data types in netcdf (and CF) are
> direct translations to commonly used binary formats in computers, and
> this one is not.
>
> hmm -- a quick peak at the netcdf4 docs says:
>
> "The richer enhanced model supports user-defined types and data structures"
>
> So maybe this could be a user defined type?
>
> Having said that, I don't support using ISO strings to define
> datetimes in CF. I understand particular use-cases, like keeping the
> original time stamp from a data collection system and the like, but
> then maybe it's really just arbitrary auxiliary text information, in
> which case maybe we don't need a standard name or custom data types at
> all.
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130327/c90ac69d/attachment.html>
Received on Wed Mar 27 2013 - 10:53:24 GMT
