Hi John,
I'm probably repeating what others have said, but allowing strings as
actual (rather than ancillary) coordinate values would break lots of
"quick look" software which can't plot variables which are "functions"
of a string representation of the independent variable (i.e, time). If
I'm correct about this, I think making the proposed change to CF would
be a mistake.
If the alternate string representation is stored as an ancillary
variable, a human reading the ncdump would immediately see what the
"dates" are, and the software would continue to work by reading the
actual coordinate values.
Karl
On 3/21/13 8:51 AM, John Caron wrote:
> On 3/21/2013 9:41 AM, Steve Hankin wrote:
>>
>> On 3/21/2013 8:25 AM, John Caron wrote:
>>> Probably my proposal comes down to 2 parts, which are separable:
>>>
>>> 1. Find a suitable replacement for udunits as a reference library
>>> for CF calendar dates. Unfortunately, udunits used a slightly
>>> non-standard syntax, which we need to still be legal for backwards
>>> compatibility. So its unlikely a standard library would work off the
>>> shelf. Someone needs to commit to making a library that supports CF
>>> as it evolves. Other libraries can test against it.
>>>
>>> 2. *Allow*
>>
>> Hi John,
>>
>> The crux of this debate has been whether to "allow" a new (for CF),
>> redundant encoding of time coordinates. I *think* you are suggesting
>> in your bullet #2 to allow the new syntax only in ancillary variables
>> (metadata), but not as a representation of coordinates. Can you clarify?
>>
>> - Steve
>>
>>> a suitable string syntax for date/times, probably expressed as a
>>> profile of ISO8601. Its a modest but worthwhile improvement IMO. The
>>> syntax that is already used in udunits would be ok with me. However
>>> this syntax has to be defined (it never was, unless you are yacc).
>>> In my understanding, udunits is more or less a superset of ISO. that
>>> is, its a bit more lenient in the syntax. However it adds a few
>>> restrictions, like defaulting to UTC and filling non specified
>>> fields with 0. So its not strictly a superset. The advantage of
>>> using CF process to define the syntax ("clarify the profile of
>>> ISO8601") is that we are less likely to miss some subtlety in syntax
>>> and meaning.
>>>
>>> John
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
> Hi Steve:
>
> Im proposing that time coordinates may be expressed as strings, in
> addition to the current way of using time offsets from a base date
> expressed as a string in the unit attribute. The two date string
> syntaxes (standalone and in the unit attribute) c/should be the same.
>
> Presumably we want to do either this or Aleksandar's proposal ?
>
> John
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130321/c4211eb4/attachment.html>
Received on Thu Mar 21 2013 - 10:04:21 GMT
