[CF-metadata] udunits handling of fuzzy time units

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 16 Mar 2011 16:46:53 +0000

Dear John

Thanks for your useful summary.

> - 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?

> - 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.

> - 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.

> - 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?

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?

Best wishes

Jonathan
Received on Wed Mar 16 2011 - 10:46:53 GMT