I think one the important factors, implied if not stated is what is
meant by accuracy.
One approach is to set all non specified values to 0, such that:
1930-01-01 == 1930-01-01T00:00:00Z
Another appraoch is to take the accuracy to be encompassing, such that:
1930-01-01 == 1930-01-01T00:00:00Z to 1930-01-01T23:59:59Z
1930-01 == 1930-01-01T00:00:00Z to 1930-01-31T23:59:59Z
(I have assumed a gregorian calendar and that seconds provide
sufficient accuracy, whilst sub-seconds are merely optional)
to my mind 1930-01 and 1920-01-01 are implicitly bounded quantities, not
instants in time, January 2003 is the whole of the month, no more, no
less.
The second appraoch would then give:
1 months since 1930-01-01 == 1930-02-01
All this becomes very calendar dependent, which I think the calculations
need to be.
> 'udunits converts units like months and years to a fixed number of
seconds'
This seems to me to be an issue, something which needs addressing,
either by changing the behaviour or deprecating it.
mark
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu
[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Nan Galbraith
Sent: 16 March 2011 13:33
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
Is the whole problem just that when udunits calculates ISO string dates,
it doesn't use the resolution implicit in the reference date and units?
That seems like an easy problem to solve, without throwing out udunits.
> 1 months since 1930-01-01 == 1930-02-01
The argument that months & years are inappropriate units for time delta
is, sorry, wrong. They'd obviously only be used where the data was on a
per-month or per-year basis, and the variation in the actual length of a
month or year were either taken into account (i.e. by averaging
different length time bins) or was unimportant (as in some models).
The current system provides the flexibility to handle lots of different
models of data time.
What would be very useful would be to have a well defined method to
describe the resolution of the time coordinate, which is missing in CF;
we use a "resolution" attribute, but it's not a standard, so has limited
value. We also use the old "fortran_format" attribute, and that (or
something like it) should be used in udunits for converting calculated
times to ISO strings.
Nan
> because udunits converts units like months and years to > a fixed
number of seconds, one cant really use things like > months and years
as units, since you get things like this:
> 0 months since 1930-01-01 == 1930-01-01T00:00:00Z
> 1 months since 1930-01-01 == 1930-01-31T10:29:03Z
> 2 months since 1930-01-01 == 1930-03-02T20:58:07Z
> 3 months since 1930-01-01 == 1930-04-02T07:27:11Z
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Mar 16 2011 - 08:21:25 GMT
