⇐ ⇒

[CF-metadata] udunits handling of fuzzy time units

From: John Caron <caron>
Date: Tue, 15 Mar 2011 10:37:34 -0600

Hi Steve:

On 3/15/2011 10:13 AM, Steve Hankin wrote:
> 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 guess the problem here is that i think date is not a unit of measure.
do we disagree on that?


> 1.
>
>
>
> 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.

im sure we agree that making things human readable is good, it makes it
more likely that errors will be noticed. we are just discussing the best
way to do that.

>
> 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
>
so im looking at a 100 year dataset of monthly averages. Theres nothing
sloppy about wanting to encode it using "month since start" or "year
since start" to indicate the starting and ending dates. Its the
limitation of udunit processing this as if dates are dimensional units
thats the problem.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110315/d53c0a01/attachment-0001.html>
Received on Tue Mar 15 2011 - 10:37:34 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒