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