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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110328/5b019733/attachment-0001.html>
Received on Mon Mar 28 2011 - 10:31:47 BST
