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 *
*******************************************************
Received on Wed Mar 16 2011 - 07:33:04 GMT
