* 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, [email protected] wrote:
Message: 1
Date: Tue, 15 Mar 2011 09:13:51 -0700
From: Steve Hankin<[email protected]>
Subject: Re: [CF-metadata] udunits handling of fuzzy time units
To: John Caron<[email protected]>
Cc: [email protected]
Message-ID:<[email protected]>
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
