Hi all, I've stayed out of this for a long while, but this is bringing
back fond memories of the early days of ESMF:-). Ah, that ESMF time
manager... it was a thing of beauty.
I think the issue is that "time instants" and "time intervals" are
different quantities.
Time instants can have a reference time instant (hence, the "since"), a
calendar, and calendar-dependent units, such as "month".
Time intervals can only have SI units (seconds, minutes, hours). Days
and years introduce difficulties once you take on the requirement of
accommodating other planets in your software. Months of course are a
problem. (The expectation that you can add and subtract the same
interval from an instant and get back to the original is violated with
months).
Don't all our difficulties arise out of trying to describe intervals and
instants using the single thing called "time"?
Steve Hankin writes:
On 3/26/2011 9:11 AM, Karl Taylor wrote:
Dear all,
I think "3 days since 1970-01-01" is a sensible statement, with "3" being
the number and "days since 1970-01-01" being the units. Would anybody
normally interpret "5 3 days since 1970-01-01" as meaning "15 days since
1970-01-01"? If not, then I don't think we should allow a unit of "3 days
since 1970-01-01". This would be just as confusing as allowing a unit of
"3 meters" and interpreting "5 3 meters" as "15 meters". Since we don't
allow "3 meters" as a unit, why should we allow "3 days since 1970-01-01"
as a unit?
Hi All,
Karl has challenged us to think about a broader (and difficult) question.
CF has not been as thorough as it needed to be in standardizing time units.
It merely appealed to udunits, despite known limitations. This has resulted
over time in various encodings that were not properly considered in the
formulation of CF
* the use of *multiple calendars* -- after discussions this resulted
in enhancements to CF document ... and thereby implicit conflicts
with udunits, since it does not support the calendars
and
1. the *use of "months" as a unit of measure*, with the intention
that this refer to calendar months of varying length ... not a
"unit of measure" by the normal meaning of that word
2. *pre-pending a number to some units* in order to create custom
units -- e.g. "3 days since 1970-01-01"
The question before us is, does the fact that there are some existing "CF"
files that utilize these encodings, require that those encodings be
formalized into CF? It is hard to say "no" in such cases, because doing so
creates inconvenience for our colleagues and their users. Next time around
we could find ourselves on the wrong side of the "no" answer and be
inconvenienced ourselves. On the other hand, we need to recognize this
impulse as a problem, itself. It is one of the "design by committee"
impulses that leads standards to grow bloated and inconsistent over time.
Quote Henning <http://queue.acm.org/detail.cfm?id=1142044>, 'To create
quality software [or standards], the ability to say "no" is usually far more
important than the ability to say "yes."'
Karl's example illustrates the community problem. An encoding of times with
units of "3 days since 1970-01-01" may be convenient and readable to the
project that performed a 3-day measurement cycle and created the file, but
what about the generic application reading the file? How should software
label the time axis of a plot? Should it have tic marks spaced at 3 day
intervals documented as intervals of "3 days since 1970-01-01"? How
peculiar! If the software takes the more conventional approach of labeling
the time in days or in calendar formatting, seeing the plot marks at 3 day
intervals will convey the contents of the data very effectively. In which
case, what has CF gained by allowing units of "3 days since 1970-01-01"? And
what has it lost?
We should look at each of these questions from the point of view of the
complexity of the software *reading* the file. From our colleague Bryan
Lawrence, "In general my rule of thumb is organise the data for the
consumers, not the providers!"
- Steve
==============================
Best regards,
Karl
On 3/26/11 6:46 AM, Don Murray wrote:
John-
On 3/25/11 4:54 PM, John Caron wrote:
On 3/22/2011 6:53 AM, John Caron wrote:
Consider:
int time(sample=1001);
:long_name = "Measurement time";
:standard_name = "time";
:units = "days since 1970-01-01";
vs
int time(sample=1001);
:long_name = "Measurement time";
:standard_name = "time";
:units = "3 days since 1970-01-01";
values = 1, 2, 3, ...
are these equivalent or does the second one mean every 3 days ? Is the
second one illegal ?
Im am going to assume that the second form is illegal, that is, you may
not have a number in front of the unit in a "time coordinate unit" (CF
section 4.4)
I agree with Beno that it should be legal. GrADS gives their units in
terms of N (minutes, hours, days, months, years) from a reference time.
When I wrote the GrADS IOSP, I originally was using this syntax,
because then your time coordinate values are 0,1,2,..... However, 3mo
intervals came up with the problems that you have shown here, so I
converted everything to hours since the base date. But, if we had a
library that would compute 3mo since 2011-04-01 as 2011-07-01, I would
revert to that syntax because it is closer to the original GrADS
definition.
Don
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
V. Balaji Office: +1-609-452-6516
Head, Modeling Systems Group, GFDL Home: +1-212-253-6662
Princeton University Email: v.bal...@noaa.gov
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata