Dear John > 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.
CF is a metadata standard, not a software library. It is a bit sloppy, perhaps, that we imply that udunits is a component of CF. In fact CF depends on udunits only to provide the format of legal units strings. If it would help, we could explicitly write down the legal formats of date-time strings in the CF standard document. This would then be the specification for any software which aims to support CF. There could be several implementations, and that may be helpful because some languages are more portable than others. Therefore to make the specification clearer, maybe we would write down more explicitly and algorithmically what is the definition of the various CF calendars, as part of the standard, and add an appendix which gives examples in all the calendars. These would be test cases for CF-compliant software. > 2. Allow 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. Obviously opinion is divided on this, if it means allowing time-date coord variables which are string-valued, as an alternative to the numerical ones. I'm not convinced this is a good idea. I think it would just make software more complicated because of having to support two conventions, and I'd prefer to make life easier for the user by making sure that CF-compliant software offers convenient encoding and decoding of date-times from/to human-readable formats, which could include ISO. Best wishes Jonathan _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata