[CF-metadata] New standard name: datetime_iso8601

From: John Caron <caron>
Date: Sat, 23 Feb 2013 14:41:51 -0700

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.

>
> 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
Received on Sat Feb 23 2013 - 14:41:51 GMT