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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
