On 3/16/11 10:21 AM, Hedley, Mark wrote:
> I think one the important factors, implied if not stated is what is
> meant by accuracy.
Sorry, it should really be "resolution"; we also use accuracy with our
time variable (for real-time data) to describe clock drift.
In our previous discussion on this, we did use the term accuracy:
mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html,
'New standard names for satellite obs data (time as ISO strings)'
Jon quoted the wikipedia description of ISO 8601:
/> From Wikipedia (
http://en.wikipedia.org/wiki/ISO_8601):
/>/
/>/ "For reduced accuracy, any number of values may be dropped from any of
/>/ the date and time representations, but in the order from the least to
/>/ the most significant. For example, "2004-05" is a valid ISO 8601 date,
/>/ which indicates May (the fifth month) 2004.//
/
Udunits should really treat the reference date this way.
Nan
//
>
> One approach is to set all non specified values to 0, such that:
> 1930-01-01 == 1930-01-01T00:00:00Z
This seems to be incorrect; the
> 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 *
*******************************************************
Received on Wed Mar 16 2011 - 09:52:26 GMT
