On 2/23/2013 1:41 PM, John Caron wrote:
> Hi Chris, and all:
>
> On 1/11/2013 2:37 PM, Chris Barker - NOAA Federal wrote:
>> On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
>> <aleksandar.jelenak at noaa.gov> wrote:
>>
>>> Here's the modified proposal for the datetime_iso8601 standard name:
>> ...
>>> String representing date-time information according to the ISO
>>> 8601:2004(E) standard.
>>
>> I think we should NOT adopt a string option for datetime variables.
>>
>> To quote Jonathan Gregory:
>>
>> """
>> In CF we have always applied the
>> principle that we only add to CF when there is a need to do so, i.e.
>> there is
>> a use-case for something which cannot already be represented in CF
>> """
>>
>> We already have a way to encode datetimes in CF-netcdf.
>
> Yes, but <time since date> is not as good as <date> as an encoding.
> The <time since date> is a result of cramming calendar handling into a
> units package.
>
> I would advocate both should be allowed.
Hi John,
The bell is ringing, "round three" on the ISO dates issue.
The arguments *for *supporting ISO dates are:
1. they are the clear standard for date/time interoperability and
deserve support _of some kind_ in CF
2. they offer good human readability
3. there are widely available support libraries (though with problems
as articulated below)
The arguments *against *are:
1. introducing a new encoding information that is already fully
supported is a clear loss of interoperability that won't get ironed
out of CF for years -- until older applications are updated to
support it
2. introducing two encodings for the same information is a clear
increase in complexity
3. ISO dates cannot handle all of the situations the CF commonly
encounters -- climatologies, non-leap calendars, etc. This requires
non-standard extensions which are much less well supported than the
base ISO standard. Extra complexity.
4. The base ISO date standard is overly complex for CF needs. CF would
need to profile it down. More complexity.
5. ISO dates are in fact *NOT* a good encoding for the needs of a
coordinate axis. They are a good external representation and a good
interchange format. They make nice metadata representations of
dates. They muddy the simplicity of time as a measurable,
computable quantity that monotonically increments like other
coordinates. ISO dates are not, themselves, typically encoded as
ISO date strings in their internal representation in code (nor
should they be in CF).
==> All of the advantages of ISO dates can be build into CF _if we add
just a couple of tools in the CF support libraries_
* add easy ability for an application program to convert between ISO
dates and CF representations ==> simple code
* easy ability for humans to read units-since-T0 encodings in CF ==>
already included in ncdump today
IMHO it is the client libraries that hold the answer to this question.
They give CF all of the advantages without increasing complexity or
compromising interoperability.
- Steve
>
>>
>> I believe this proposal resulted from the discussion about adding a
>> more flexible approach to datetimes in the CF Data Model. I think
>> that's a good idea, but separate from what encoding is used in
>> CF-netcdf. ( see my recent note for more detail about the difference
>> between and encoding and a data model ).
>>
>> 1) Having multiple ways to encode the same data in file format adds
>> complication to all client code -- client code would need a way to
>> process both ISO strings and "time_unit since datetime"
>
> client code already has to parse the "date" in "time since date". So
> theres no extra code involved.
>
>
>>
>> 2) Any client code that can process ISO strings is likely to need to
>> convert them to a client-specific datetime representation anyway, in
>> order to plot, calculate with, etc them.
>>
>> 3) Any client library that can process ISO strings is very likely to
>> be able to also work with "time_unit since datetime" encoded data
>> anyway -- and it had better, as that encoding is part of the standard
>> anyway.
>>
>> As a result, we would be complicating client code, and getting no new
>> functionality.
>
> We get new functionality in that "date" is clearer than "time since
> date", and more likely to be correctly understood by non CF specific
> software and users of our data in 100 years when theres no more CF
> discussion group to help people out.
>
> when you have non-standard calendars, the difficulty is compounded
> many times over. How many seconds since 1970 is April 3, 2045 at 1:13
> am in the no-leap calendar? Are you sure? What if you could just put
> into your file "2045-04-03T01:13:00" ?? Even rocket scientists can do
> that ;^)
>
>>
>> The one advantage I can see at the moment is that simple, non-CF-aware
>> clients, like ncdump, could easily present a nice human-readable
>> format. But I don't think that is worth the additional complication.
>
> Ideally file encodings should be as independent as possible from
> libraries and applications. We have historically had an unfortunate
> dependence on the udunits reference library for date parsing. We are
> slowly unwinding that dependence. I think in this case widening the
> allowed encoding for datetimes is well worth the complication.
>
> Regards,
>
> John
> _______________________________________________
> 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/20130224/3f9a4727/attachment-0001.html>
Received on Sun Feb 24 2013 - 12:07:08 GMT
