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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130321/1b3f66ad/attachment.html>
Received on Thu Mar 21 2013 - 09:51:54 GMT