⇐ ⇒

[CF-metadata] New standard name: datetime_iso8601 (standard_name or units?)

From: Steve Hankin <steven.c.hankin>
Date: Thu, 28 Mar 2013 09:56:12 -0700

CF does support using ASCII strings for enumerated lists of named
objects: PI name, ship names, species names, etc. An important
encoding ability. That capability is not in question.

     - Steve


On 3/28/2013 9:36 AM, John Graybeal wrote:
> On Mar 28, 2013, at 17:54, Steve Hankin <steven.c.hankin at noaa.gov
> <mailto:steven.c.hankin at noaa.gov>> wrote:
>
>> netCDF files are in every sense "binary" files. They cannot be read
>> except by custom-built utilities. (Or is there a constituency that
>> wants to access CF using the unix "strings" command?) In all cases
>> except the present discussion, it is the job of those custom-built
>> utilities to generate formatted string representations of the
>> information contained in the CF binary encoded variables.
>>
>> The entire current discussion would not be happening, if the
>> custom-built utilities and standard code libraries supported the
>> ability to get time information into and out of our binary files
>> using formatted ISO 8601 strings.
>
> This is arguably not true. I gave two use cases, one was the derided
> equivalent of your Unix strings command (call me crazy, it fits in
> this case!); the other was the desire to store an ASCII string of
> particular structure and meaning into the binary netCDF file, and then
> to label the information in that binary file with what it is. No more,
> and no less. (Uh, unless I think of another use case. :->)
>
> Seriously, I think some use cases, partly including my first one, go
> directly to your point -- "my tool can't print this timestamp as ISO
> 8601 so I'm going to duplicate the data as ASCII, in that ISO format,
> as a workaround" -- but the second one remains a real use case
> regardless of existing tool support for representations. And it goes
> beyond time, now that we're on this topic.
>
> The fact that most use netCDF as a strict binary encoding does not
> mean it must exclude those who want to use it to store ASCII strings.
> That is perhaps the key criterion -- the community can say "No ASCII
> string representations of anything!", or "No standard names for ASCII
> strings", if either is a constraint they really want.
>
> So, for those who want to be able to store strings, however different
> that may sound, and then label them with standard names when that's
> appropriate -- is the tent open to that? Nothing in the standard
> suggested to me it was not, though it often seems to offend
> practitioners, so maybe I've missed something.
>
> John
>
> ---------------
> John Graybeal
> Marine Metadata Interoperability Project: http://marinemetadata.org
> graybeal at marinemetadata.org <mailto:graybeal at marinemetadata.org>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130328/49e9bd6e/attachment-0001.html>
Received on Thu Mar 28 2013 - 10:56:12 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒