On 3/15/2011 12:07 PM, Steve Hankin wrote:
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
Hi Steve:
i understand why it seems "date" is a " way of formatting time units",
but there are enough differences here to take pause.
"time" is a duration of time, whereas "date" is an instant of time, its
not a formatting of "time duration".
a calendar date/time (Feb 23, 1999 13:33 Z) is a representation of an
instance of time which is human readable, and therefore less prone to
errors because it can be easily noticed. So that representation has
advantages over something that requires software to interpret. i
understand that ncdump is now able to dump date coordinates in ISO
formats, using a version of cdtime to handle the calender options. so
thats a nice feature that gets us a long ways.
if time-based calculations are being done incorrectly, its a good reason
to add that functionality to a standard library. but its not because
calendar representations of time instants are somehow defective.
Regards,
John
PS: a couple of my emails about this got lost somewhere(!) Maybe thats a
blessing in disguise (?) If they still seem relevent, i will repost....
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
