On 3/17/11 5:20 PM, John Caron wrote:
On 3/17/2011 12:19 PM, Steve Hankin wrote:
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".
"time" is a bit confusing here, after all, we talk about "what time is
the meeting?", but also "how much time has passed?". Which I guess is
why some libs define a "datetime" type and a "timedelta" type.
however it can be represented as "duration since calendar time",
right.
Steve, one can talk about "1000 meters north of 45°N--65°W" does that
make lat-long a unit or length? (note that that is not clearly defined
unless you specify a datum -- analogous to a calendar with datetimes)
anyway this is why udunits cant be incrementally extended to do more
better time unit handling, we need more sophisticated calendar handling.
right, Calendars are a mess -- really a different set of machinery.
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.
I think apporach #1 is the best bet for what I've been calling
"catagorical" datetimes -- i.e. montly averages and the like. Perhaps CF
should adopt that, rather than trying to shoe-horn categorical uses into
approach #1.
On 3/18/11 3:11 AM, Schultz, Martin wrote:
PS: I do disagree with Christopher when he says ''"30 days since 31
Jan 2008" is perfectly well defined.'' - do you refer to 00 UTC or 12
UTC on 31 Jan 2008? Or even 00:00 UTC or 01:02:30.3625132 h UTC? OK:
if you define an "oceanographic calendar" (where anything shorter
than a day doesn't matter), you could have a rule that all hours,
minutes, seconds, milliseconds, etc. are mapped onto one value (say
00:00:00 h UTC). But you will need to define this rule in order to
give a meaning to your calendar.
Indeed you do -- I suppose I should have written "could be perfectly
well defined". But is this really any different than specifying a
location with integer degrees lat-long? How many minutes or seconds are
there? or even integral number for meters? what about centimeters or
millimeters? It comes down to "resolution" or "precision". If more
detail is not defined, the assumption is that the precision of the data
is not that greater that what was expressed.
John -- I'm wondering if you have any idea about what the API of a
reference lib should look like? If a time axis is defines as: "calendar
months since January, 2008", what sort of functions do you image would
exist to deal with that?
Also, I don't think I've seen any suggestions for how to express things
like monthly averages -- i.e data that corresponds to a particular
month, but not of any particular year.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
