Hi all, NetCDF-Java has no issues with T or no T in an ISO time string.
Sean On Friday, September 23, 2016, Ethan Davis <[email protected]> wrote: > 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 <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> On Thu, Sep 22, 2016 at 3:38 PM, Seth McGinnis <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 >> >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
