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 at 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.balaji at noaa.gov
Received on Mon Mar 28 2011 - 11:01:54 BST
