[CF-metadata] udunits handling of fuzzy time units

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

On 3/16/2011 11:15 AM, Jonathan Gregory wrote:
> Dear John
>
>> Suppose we added the UTC_Calendar to CF, which tracks leap seconds
>> etc. So if one had the time coordinate "days since 1800-01-01" with
>> values = "0,1,2,3..." and we need the resulting coordinates to be
>> "1800-01-01", "1800-01-02", "1800-01-03", "1800-01-04",.... which in
>> this calendar gives an uneven number of seconds between coordinates.
>>
>> So all timeUnits (except seconds) now mean "increment the calendar
>> field", not "add x secs to base", that is, its calendar dependent if
>> any timeUnit implies a fixed number of seconds.
> In fact that also raises the same problem as I did in my last email. If a
> second is removed, there will be some occasions when adding 1 day to a given
> time will not have an obvious meaning, because the corresponding time a day
> later may not exist in the calendar. A rule is needed to resolve that.

the best i can think of is "increment the field, if that is not a valid
date, decrement the next smaller field until you have a valid date"

so "1 calendar_month since 2008-01-31T23:59" -> 2008-02-31T23:59 ->
2008-02-29T23:59

im not sure how leap seconds work, does one have 61 seconds in some
minutes ? this might change the allowable strings (aka the grammer).

>> In that case, then fractional values may not make sense(?)
> It will depend on the calendar, presumably. In the 360_day calendar, all the
> units of time have fixed length. In the UTC calendar, none of them do except
> seconds, apparently. Fractions are OK with fixed-length units. In the 360_day
> calendar, 0.5 year means 180*86400 seconds exactly.

from an implementation POV, it would be nice to not have fractional values

> Cheers
>
> Jonathan
Received on Wed Mar 16 2011 - 11:38:37 GMT