[CF-metadata] CF-metadata Digest, Vol 95, Issue 10

From: Bob Simons <Bob.Simons>
Date: Tue, 15 Mar 2011 15:20:57 -0700

* Isn't part of the problem related to trying to convert a time range
(e.g., when "months since" is (mis)used for monthly summary data) to a
time point (1970-03-01T00:00:00)?
(Steve Hankin:) aren't there any legitimate uses for referencing a month
as a time period? Isn't a monthly mean a legitimate statistic and thus
wouldn't something like "calendar_months since" be a better way to
represent monthly means than a specific time point?

Perhaps CF needs guidance on dealing with time ranges. Or, perhaps we
should just use separate, instantaneous beginTime and endTime variables,
which would solve the problem for any time range (e.g., the beginTime
and endTime for a trawl).

* Isn't part of the problem related to udunits having single values for
the length of a month and a year, and not offering calendar-oriented
alternatives suitable for use with calendar calculations?
How about calendar_month and calendar_year?
I admit they couldn't have exact definitions in terms of seconds, but
they could be useful for date/time calculations.

* Regarding human readable vs computer readable:
The CF standard says "It is equally important that the metadata be easy
for human users to write and to understand." In that spirit, I encourage
support for something like "calendar_months since" and "calendar_years
since" for data related to monthly or yearly data.


On 3/15/2011 9:28 AM, cf-metadata-request at cgd.ucar.edu wrote:
> Message: 1
> Date: Tue, 15 Mar 2011 09:13:51 -0700
> From: Steve Hankin<Steven.C.Hankin at noaa.gov>
> Subject: Re: [CF-metadata] udunits handling of fuzzy time units
> To: John Caron<caron at unidata.ucar.edu>
> Cc: cf-metadata at cgd.ucar.edu
> Message-ID:<4D7F903F.7020809 at noaa.gov>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> John et. al.,
>
> It looks like this thread has reached reasonable conclusions:
>
> 1. units of days (or secs or mins) can provide an accurate encoding
> for months ("days since 1930-01-01")
> 2. "units of measure" should not be quantities that vary
> 3. udunits could in principle offer calendar type-sensitive support
> for units of "months" or "years", but doing so would likely break
> backwards compatibility and would get nasty-complicated as a
> result of bullet #2
>
> I'd like to add a response to this concern:
>
>> option 1 is suboptimal because one has to calculate the days
>> correctly. Also it makes the time coordinates not human readable, eg:
>
> Here I think concerns of human-readable formatting and convenience are
> sliding into issues of accurate encoding. ncdump already offers an
> option to format these values as dates. Ncgen could in principle offer
> conversions to encode various human-friendly formatting options.
>
> The larger question of "months" used as units of time measure is an
> ingrained problem of sloppy earth science. =-O>:o (heresy!) Regarding
> Gregorian months (unequal length) as a simple numbered sequence, 1, 2,
> 3, 4 .... continues to promote countless sloppy (wrong) calculations --
> erroneous derivatives, integrals, variance, ... any calculation that
> attempts to use the month number as encoded as a unit of time measure.
> Glossing over these errors seems often to be the norm, rather than the
> exception. This is one of those rare areas where our responsibility as
> software developers should be to push back against sloppy science, by
> offering software that makes it easy to do the calculations correctly,
> and help to end these sloppy practices. I'd welcome seeing this
> discussion elevate to our science colleagues.
>
> - Steve
>

Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
Received on Tue Mar 15 2011 - 16:20:57 GMT