Dear all,
I haven't had time to follow all the discussion in detail, but in
general I think CF should not add additional complexity unless the
current way of encoding time is incomplete. As far as I know the
encoding is indeed complete and given correct specification of the units
(which include basetime) and a calendar, the calendar date/time can be
calculated. This indeed requires a smart library, but I think that Bob
Drach's CDMS correctly performs such a calculation.
I'll try to go back and read the arguments, but I think I agree with
most of what Steve Hankin has said.
Best regards,
Karl
On 3/21/11 10:14 AM, Steve Hankin wrote:
>
>
> On 3/17/2011 5:20 PM, John Caron wrote:
>> On 3/17/2011 12:19 PM, Steve Hankin wrote:
>>>
>>>
>>> On 3/17/2011 9:50 AM, Christopher Barker wrote:
>>>> On 3/16/11 8:47 AM, John Caron wrote:
>>>>
>>>>> 1. time instants vs time duration
>>>>> - one must distinguish between dimensional time ("time duration",
>>>>> units="secs"), and calendar time ("time instant", or "point on the
>>>>> time
>>>>> continuum") *which is not dimensional. *
>>>>
>>>> yup -- key clarification in all this.
>>>
>>> I think we are leading ourselves astray here. _A point in time has a
>>> dimension._ It has dimensions of "time". Whether the units happen
>>> to be days, months, years or whatever depends upon the encoding.
>>> But it definitely has dimensions of time. The date-time string
>>> loses its meaning if we see it as detached from the axis that gives
>>> it a dimensionality.
>>
>> in "dimensional units", "secs" is a base dimensional unit, and it
>> means "duration", eg watts = joules/sec, the sec is a time duration,
>> not an instant of time.
>>
>> "time" is not a dimensional unit, it refers to a point on the time
>> continuum. it does not have dimensional units of "secs", that is, it
>> cannot be converted to a duration in "secs".
>
> Hi John,
>
> Beg to differ on these most fundamental of issues. *All times* (all
> "points on the time continuum") indicate intervals. Typical
> date-time strings (e.g. "21-MAR-2011:10:10") are an artfully contrived
> way of stating an interval of time relative to a precise zero
> reference that is 2011+ years ago, while still retaining high
> resolution (fractions of seconds) in that interval measurement. But
> perhaps this is not a point to pursue much deeper without beer in hand.
>
> To me the most important point is just this: before proposing new
> libraries and new data models, there should be an effort to see
> whether there is any functionality that cannot be very satisfactorily
> handled by adding some convenience methods to the encodings that CF
> and udunits have already standardized.
>
> - Steve
>
>>
>> however it can be represented as "duration since calendar time", and
>> the machinery of dimensional units can be used for the duration part.
>> but theres still that "calendar time" part of udunits "time unit"
>> handling, and udunits does the very simplest handling it can.
>>
>> hmm, can i add any more "quotes" ??
>>
>> anyway this is why udunits cant be incrementally extended to do more
>> better time unit handling, we need more sophisticated calendar
>> handling. im sure there are other libraries that have some or most of
>> this solved (cdtime has some), and i think we should find those and
>> build a reference library. We could, for sure, add this new stuff
>> into udunits, but the point is that we need new stuff.
>>
>> currently CF references udunits as the reference library for time,
>> and while reference libraries are not strictly needed, in practice
>> they are Very Good.
>>
>>>
>>> There are two ways in which dimensions (positions and intervals) can
>>> be handled. Each of them is self-consistent:
>>>
>>> 1. *represent positions as strings*.
>>> * Then create special functions to compute the implied
>>> distance between those string representations. In this
>>> outlook units must be specified when the interval is
>>> computed.
>>> 2. *represent positions with a zero reference, and an offset value.*
>>> * Then create special functions to generate formatted
>>> strings representing positions along the axis. In this
>>> outlook units must be stored with the representation.
>>>
>>> Udunits consistently follows approach #2. It is a complete and
>>> self-consistent outlook that is capable (with additional API
>>> functions) of handling formatted strings for all dimensions. It is
>>> very well suited to numerical analysis tasks.
>>>
>>> GIS systems have advanced approach #1, because they primarily treat
>>> Z and time as metadata tags (strings). In general approach #1 is
>>> best suited to situations where you are working primarily with metadata.
>>>
>>> What do we gain by mixing the two approaches together and what do we
>>> lose? I'd argue that consistency, simplicity, elegance etc. should
>>> be the primary bases of this debate.
>>
>> From my POV, the problem is that users need more expressiveness for
>> the calendar time. I certainly do. For yearly data, "years since
>> base_date by calendar field" (or whatever) is consistent, simple and
>> elegant.
>>
>> John
>>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110321/544305be/attachment-0001.html>
Received on Mon Mar 21 2011 - 11:55:19 GMT
