On Thu, Sep 22, 2016 at 3:38 PM, Seth McGinnis <mcginnis at ucar.edu> wrote:
> I hesitate to support encouraging the use of the T because in my
> experience, approximately 0% of existing NetCDF files have it.
>
in my experience, > 0% (but still small).
But that isn't the right question -- given that few existing ?CF files have
the T, we can be confident that code that expects to be able to parse CF
can parse it without the T.
The question is: how much code that expects to be able to parse CF can not
handle the "T":
UDUNITS can
The Python netCDF4 lib can
Anything that can parse ISO stings can
I'm going to venture a guess that the netcdf Java libs can (anyone know for
sure?)
Which covers a lot of ground, but not all the various custom Fortran and
what have you code out there.
So I expect leaving the T out is going to have to remain as "best practice"
for CF
> There is benefit in encouraging alignment with a separate standard, but
> it comes at the cost of increasing the amount of disagreement in the set
> of all CF-compliant files out there. It's not obvious to me that the
> former is greater than the latter.
>
again, disagreement with the files isn't really relevant -- disagreement
with parsers is key.
I'd be interested if anyone on this list can say "my code won't parse the
T" -- that would settle it.
It also worries me that there is a small but fundamental mismatch
> between the two standards: ISO 8601 is only intended to support
> real-world dates and times using the Gregorian calendar, while CF also
> needs to support non-standard model calendars. Being able to use
> software that understands ISO datetimes when working with NetCDF data is
> great right up until the point that it gives you the wrong answer
> because it doesn't understand the "calendar" attribute and ignores it.
>
I think this is totally irrelevant -- we're only talking about the datetime
string here.
an pure ISO 8601 code isn't going to understand stuff like "seconds since"
anyway -- of course, you'll need a CF compliant reader to do more.
As it stands, there are multiple ways to write a datetime string in CF --
all I'm suggesting is that we pick one as "best practice", and make that
clear in the docs.
If we ever get to the mythical CF2 or "pedantic CF" standard, we could make
it the one and only way to express datetimes.
If we're going to move to align CF more closely with external standards,
> is there any way to also apply corresponding pressure on external
> systems to better accommodate CF?
>
one's that aren't CF-focused anyway? I doubt it :-(
and I'm not sure what you are suggesting -- that we should ask that all
datetime string parsers should read non-iso compliant strings? I don't know
that I'd ever suggest that anyway.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160923/c5e51bdb/attachment-0001.html>
Received on Fri Sep 23 2016 - 13:26:13 BST
