Hi Chris,
> I'm going to venture a guess that the netcdf Java libs can [handle the > "T"] (anyone know for sure?) Yes, the netCDF-Java library can parse date/time strings with the "T". Ethan On Fri, Sep 23, 2016 at 1:26 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Thu, Sep 22, 2016 at 3:38 PM, Seth McGinnis <mcgin...@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.bar...@noaa.gov > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata