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....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110315/8836bdf1/attachment-0001.html>
Received on Tue Mar 15 2011 - 13:18:37 GMT
