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