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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
