On 3/15/2011 9:28 AM, John Caron wrote:
On 3/15/2011 9:19 AM, Benno Blumenthal wrote:
I am sorry, but this conversation is more confusing that it needs to
be -- once calendar 360_day is chosen, there is nothing "fuzzy" about
month or year, and once calendar 365_day or 366_day is chosen, there
is nothing "fuzzy" about year. udunits does not support calendar,
so its poor choice of month/year support is not an issue -- if it did
support calendar (which is in the standard), then it would handle
year/month correctly for these choices of calendar.
i think the issue is that udunits is not a good reference library for
date handling, and that we should create a new reference library.
the problem with udunits is:
1) it does not support calenders.
2) it allows units of month and year, but implements them in a way
thats appropriate to dimensional units, not calendar dates.
Hi John,
I'd propose that a good way of thinking about the distinction between
dates and times is that "time" is a geospatial unit of measure , whereas
"date" (which includes "time of day") is a way of formatting time units
for human readability. The distinction is much the same as "200"
versus "140W" as an encoding versus formatting of longitude
coordinates. From this perspective what is needed is more flexible
_formatting methods for udunits times_, rather than a new reference
library that handles dates as a distinct concept. The current udunits
representations are wholly satisfactory for capturing times.
ISO 8601 has standardized the formatting of dates, which is definitely a
good thing. But too often we are tempted to borrow this standard into
science a an encoding of time. ISO dates seem to work adequately for
encoding times in the world of finance, social sciences, etc, because
the primary purpose of the encoding is to provide a human-readable
metadata stamp. Computing time differences is an occasional operation
in this context; time-based computations, such as derivatives,
smoothers, and integrals are much rarer. It is a safe bet that when
time-based calculations are done, they are frequently done incorrectly
-- as when we see "monthly" smoothing and averaging -- because they have
bypassed the precise (and much simpler) definition of time. Treating
January and February as equal "units" introduces a 10% error in many
calculations! How rare for our other measurements to be this sloppy in
climate science, and how easily this could be fixed.
- Steve
- Steve
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
