Dear all,
in our work, we have often been confronted with the current limitations where the only times allowed by CF are "real" times using the "days since date" syntax and assuming the Gregorian calendar. We often have "climatological" fields as model input data, where monthly variation is included, but we don't care whether the field is valid for the 14th or 15th of February. Also, much of our output is analyzed as monthly means and we happily accept that some Februaries contain an extra day. It's still a month, and variations in weather patterns don't change with leap year anyhow.
In my opinion, Steve hit the nail on the head when he writes:
> There are two ways in which dimensions (positions and
> intervals) can be handled. Each of them is self-consistent:
>
> 1. *represent positions as strings*.
> * Then create special functions to compute the implied
> distance between those string representations. In this
> outlook units must be specified when the interval is computed.
> 2. *represent positions with a zero reference, and an offset value.
> * Then create special functions to generate formatted strings
> representing positions along the axis. In this outlook
> units must be stored with the representation.
>
So, if new calendars are defined/introduced, they must come with a self-consistent (and complete) set of rules how to compute differences and how to map one unit (days, weeks, months, years) onto the other. Within these rules you can of course disallow certain units (see Python's timedelta), that's erfectly legal. Once these rules are clear, it would be no problem to deal with any kind of calendar (even including the poor person who models the atmosphere on Venus or Mars which have very different calendars). You can then even transform data from one calendar into the other and you know what you will get (this is helpful if you construct such climatologies from daily model output, for example). It doesn't necessarily mean that the transformation must work "bidirectional" (can't find the correct english word for what I want to say here), i.e. "February 12 of year 203" in a "360 days" calendar (as often used in paleo studies) can be translated into "February 12, 1834" (if you define that your base year was
1631, which will be somewhat arbitrary), but "February 12, 1834" might not necessarily be converted back into "February 12, 1834", but could be some other date. Indeed, this is the "fuzziness" of the subject - here is where it comes in. Within each calendar, there should not be any ambiguities.
Hope, this is useful,
Martin
PS: I do disagree with Christopher when he says ''"30 days since 31 Jan 2008" is perfectly well defined.'' - do you refer to 00 UTC or 12 UTC on 31 Jan 2008? Or even 00:00 UTC or 01:02:30.3625132 h UTC? OK: if you define an "oceanographic calendar" (where anything shorter than a day doesn't matter), you could have a rule that all hours, minutes, seconds, milliseconds, etc. are mapped onto one value (say 00:00:00 h UTC). But you will need to define this rule in order to give a meaning to your calendar.
= Dr. Martin G. Schultz, IEK-8, Forschungszentrum J?lich =
= D-52425 J?lich, Germany =
= ph: +49 (0)2461 61 2831, fax: +49 (0)2461 61 8131 =
= email: m.schultz at fz-juelich.de =
= web:
http://www.fz-juelich.de/icg/icg-2/m_schultz =
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Received on Fri Mar 18 2011 - 04:11:54 GMT
