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.barker at noaa.gov> wrote:
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160923/ebbb568d/attachment.html>
Received on Fri Sep 23 2016 - 17:21:21 BST
