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