On 3/16/2011 8:47 AM, John Caron wrote:
On 3/16/2011 3:57 AM, Jon Blower wrote:
Hi all,
There have been multiple interesting sub-threads of this
conversation, and I'm getting them a bit tangled, not helped by my
email client apparently not distinguishing clearly between quotes and
new material.
John C. - are you in a position to make a summary and/or concrete
proposal to CF, based on all this?
Cheers,
Jon
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Heres the issues as I see them, and my proposed resolutions. Im being
very brief, and not summarizing others' POV.
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 continium") which is not dimensional. *
Hi John,
I hope there is still an opportunity to discuss and debate the
fundamentals here. In the end there are many ways of thinking through
the problem that will all lead to usable software. So this is not a
question of a "right or wrong" way to look at the problem. The question
is, for which purposes should the software be optimized. Since the
target in question is CF -- climate and forecast -- I'd argue that*the
software design should be optimized for quantitative earth science*, by
which I mean we expect to be doing calculations on the data on all four
axes. In many cases similar calculations across all axes --
derivatives, integrals, smoothers and other convolution filters, Fourier
transforms, gap-fillers, interpolations, regridding, .... Displaying
pictures and labeling coordinates is only the tip of the iceberg.
Here's where I differ on the foundation concept: _*All*_ units of
space-time measure have the same basic properties: _the units of measure
represent intervals, not positions._ _To define a position requires both
a unit of measure and a "zero reference point". _ Longitude units, in
particular, share the very same complexities that time has. Namely,
encodings of longitude may differ in their zero reference point
(Greenwhich meridian or dateline); and the human-friendly formatting of
longitudes (e.g. 140W) are not friendly to numerical software. The
formatting of longitudes is helpful to humans because it translates the
encoding unambiguously onto the modulo-360 coordinate system. There is
an exact analog to each of these issues when handling time. The
difference between handling time and handling longitude is the degree of
complexity in the formatting. Whereas formatted longitudes communicate
position on just one 360-degree cycle, date-time formatting is designed
to communicate the coordinates on two cycles -- a daily cycle and a
yearly cycle -- which (inconveniently) are not in synchronization with
each other.
Where does this lead? It leads to saying that the tools and procedure
for handling times should fall back on these solid, foundation concepts
of interval and position that are needed by quantitative earth science.
_This is what udunits already does and is one reason that it has been so
very successful._ This is an alternative viewpoint to saying that time
position and time interval are distinct concepts not found on other
axes, that must be handled by a separate framework.
- calendar time always references a calendar, default calendar is
gregorian, aka standard
agree. Each calendar represents a distinct way of formatting the dates
(and positioning the time values), despite having the same encodings.
- udunits is a good reference library for dimensional time,*but not
for calendar time *
Disagree. Can we translate this statement into "udunits as-is lacks the
functions needed to input and output formatted times"? Or in more
detail: udunits lacks the specific functionality needed to translate
between encoded time values and calendar-sensitive, formatted date-time
strings. That functionality, however, can be added in an incremental
fashion. _A fundamental rethinking of concepts is not needed._
I will stop comments at this point, because the difference in viewpoint
effects all of the conclusions below.
- Steve
P.S. Together with enhancing udunits to handle the formatting of
date-time strings,it would be natural to add the same functionality for
longitudes, too. Ditto degrees of temperature -- degrees F, C and K.
Again -- the challenges of handling times are found in the other units,
too (admittedly with less complexity and MUCH less baggage attached).
------------------------------------------------------------------------
2. calendar time
- time coordinates (CF section 4.4) are calendar times
- time coordinate variables are instants in time. A bounds coordinate
(CF section 7.1) should be used to clarify the actual time range of
each coordinate. This is especially important when using cell measures
(CF section 7.2) like mean, min, max, etc.
- calendar time representation needs to be clarified
- udunits should no longer be the reference library for calendar
time. a new reference library is needed, which handles non-standard
calendars.
- udunit date representation ("n timeUnit since ISO_date") must be
retained for backwards compatibility. "month" and "year" timeUnit
should be redefined in CF version 1.x to refer to calendar fields, not
fixed length time durations. For files using versions previous to CF
1.x, udunit fixed length semantics should be used.
- the grammar for udunit date representations should be defined, so
that multiple libraries can implement it
- ISO date strings should be allowed
3. time resolution
- any calendar fields not specified must be set to 0
4. time calculations
- standard library functions for calculating time durations from
time ranges (start, end) are needed. these are calendar dependent.
_______________________________________________
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
