On 3/18/2011 4:11 AM, Schultz, Martin wrote:
> 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 w
as 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.
yes, i agree. we do have calendars in CF already ( see below). udunits
does not implement them, however. a claenddar should be defined by a set
of rules, but a reference library is needed to make sure you have the
rules correctly specified and implemented.
im less sure that there must always be a canonical way to "transform
data from one calendar into the other", but i understand that such
mappings are often needed.
4.4.1. Calendar
In order to calculate a new date and time given a base date, base time
and a time increment one must know what calendar to use. For this
purpose we recommend that the calendar be specified by the
attribute|calendar|which is assigned to the time coordinate variable.
The values currently defined for|calendar|are:
|gregorian|or|standard|
Mixed Gregorian/Julian calendar as defined by Udunits./This is the
default./
|proleptic_gregorian|
A Gregorian calendar extended to dates before 1582-10-15. That is, a
year is a leap year if either (i) it is divisible by 4 but not by
100 or (ii) it is divisible by 400.
|noleap|or|365_day|
Gregorian calendar without leap years, i.e., all years are 365 days
long.
|all_leap|or|366_day|
Gregorian calendar with every year being a leap year, i.e., all
years are 366 days long.
|360_day|
All years are 360 days divided into 30 day months.
|julian|
Julian calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110318/15479ed1/attachment-0001.html>
Received on Fri Mar 18 2011 - 13:30:55 GMT
