Hi all,
I think Steve has got to the heart of the issue with his comment, "IMHO
it is the client libraries that hold the answer to this question."
However you choose to peer into your netCDF files you are seeing them
through the lens of a "client library". And it's worth noting that
date/times aren't special in this regard, this is just as true for
floating point numbers.
With the Iris library(*), we are working towards improving the
readability and usability of date/times because we recognise that simply
displaying "35246 hours since 1970-01-01" is essentially meaningless to
a human. From what I've seen, I think we can all agree on that! So we
want our users to be able to see date/times in a human-readable form,
but that certainly doesn't mean we will represent them that way
internally.
The only real benefit I can see for the string representation is that
_some_ date/time values can be made more human-readable when viewed
through client libraries which don't support the
machine-readable-to-human-readable conversion. But if the library can't
do machine-to-human then it probably can't do human-to-machine. In which
case there's very little you can actually _do_ with the date/time values
(e.g. determine ordering or compute intervals). If the library is that
limited then adding the string representation to CF isn't really fixing
the right problem. If you'll excuse the analogy, it's like taking the
engine out of a car because the brakes don't work.
In short, I am against the addition of a string representation for
date/times.
*) Iris - a candidate reference implementation of CF implemented in
Python (http://scitools.org.uk/).
Richard Hattersley Iris Benevolent Dictator
*Met Office* FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702
Email: richard.hatters...@metoffice.gov.uk
<mailto:richard.hatters...@metoffice.gov.uk> Web: www.metoffice.gov.uk
<http://www.metoffice.gov.uk/>
------------------------------------------------------------------------
*From:* CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On Behalf
Of *Steve Hankin
*Sent:* 24 February 2013 19:07
*To:* John Caron
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] New standard name: datetime_iso8601
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.jele...@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@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
