[CF-metadata] udunits handling of fuzzy time units

From: John Caron <caron>
Date: Wed, 16 Mar 2011 11:14:49 -0600

Hi Jonathan:

On 3/16/2011 10:46 AM, Jonathan Gregory wrote:
> Dear John
>
> Thanks for your useful summary.

thanks!

>> - udunits should no longer be the reference library for calendar
>> time. a new reference library is needed, which handles non-standard
>> calendars.
> If udunits itself were extended to cover non-real-world calendars, wouldn't
> that be OK?

sure

>> - udunit date representation ("n timeUnit since ISO_date") must be
>> retained for backwards compatibility. "month" and "year" timeUnit
>> should be redefined in CF version 1.x to refer to calendar fields,
>> not fixed length time durations. For files using versions previous
>> to CF 1.x, udunit fixed length semantics should be used.
> Perhaps it would be safer and more explicit to make "month" and "year"
> *illegal* in CF 1.x. (In practice, we could assist this by providing our own
> udunits definition file which didn't contain them.) At the same time we could
> introduce new units calendar_year and calendar_month, which would require
> special arithmetic by the date-handling software, and are not convertible to
> other units of time.

i think the UTC_Calendar case that Tim brought up indicates that all
units like month, year, day, hour, (not second), should mean "increment
that field using calendar system x". if thats the case, maybe
prepending "_calendar" is not needed?

>> - the grammar for udunit date representations should be defined,
>> so that multiple libraries can implement it
> It is not perfectly obvious what it should do. n months since 1st of a month
> makes sense, but what does "1 calendar_month since 31 Jan 2008" mean, for
> instance.

a grammer just defines the set of legal strings. the semantics would
have to define the actual time instant that the string represented.

but i dont know the actual answer to your example. The most intuitive is
probably "29 Feb 2008".

>> - ISO date strings should be allowed
> Does ISO support non-real-world calendars? A problem with allowing strings is
> that they cannot be coordinate variables in CF, so they cannot be required to
> be monotonic, since they are auxiliary coordinate variables. We would need
> special rules if we wanted to enforce that. Would we have to define the rules
> for putting dates in order or is string-sorting using a default collating
> sequence a reliable method?

for ISO formats, i think the default string sort is also an "after" sort.

> To me it seems an unnecessary complication to introduce strings to represent
> dates. What we need is easy interconversion between strings and numbers, to
> make the files human-readable. ncdump supports this now, doesn't it, and is
> aware of CF calendars. Isn't that good enough?

Using strings isnt absolutely essential. the essential thing is that the
meaning of a udunit string has to be redefined, from a simple "add fixed
amount of seconds" to "increment calendar field in the calendar system
in use".

> Best wishes
>
> Jonathan

BTW, are you coming to go-essp this year?

Regards,
John
Received on Wed Mar 16 2011 - 11:14:49 GMT