Time is an issue, but temperature is not a "dimensional unit" either --
there is differential temperature (degree_Celsius/degree_Kevin, appropriate
for anomalies), and temperature scale, i.e. Celsius_scale and Kelvin_scale
differ only in the offset. Yes, the offset part does not "work" as well as
pure dimensional units. Yes, udunits does dimensional units best, but that
is not enough to do science data.
Benno
On Tue, Mar 22, 2011 at 8:30 AM, John Caron <caron at unidata.ucar.edu> wrote:
> On 3/21/2011 11: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
>
>
> Hi Steve:
>
> Well I havent had a beer yet today (6:30 am), but ill try to simulate the
> vibe ;^)
>
> I think Im using "units" in a more restrictive sense then you are. Im
> thinking about "dimensional units", which udunits handles well. Dimensional
> units are powers of base units, m^2/sec^2 for example. A "calendar time
> unit" is different, in that one never combines it with base units or takes
> powers of it. m^2 / (2011-11-01)^2 wouldnt make sense.
>
> Whether one wants to consider an instant of calendar time or an interval of
> calendar time doesnt matter so much as the fact that its not a dimensional
> unit.
>
> ? votre sant?!
>
> John
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Dr. M. Benno Blumenthal benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110322/5c9abede/attachment-0001.html>
Received on Tue Mar 22 2011 - 07:32:06 GMT
