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 <edavis at ucar.edu> 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 <chris.barker at noaa.gov
> <javascript:_e(%7B%7D,'cvml','chris.barker at noaa.gov');>> wrote:
>
>> On Thu, Sep 22, 2016 at 3:38 PM, Seth McGinnis <mcginnis at ucar.edu
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','Chris.Barker at noaa.gov');>
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> <javascript:_e(%7B%7D,'cvml','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/9e640204/attachment.html>
Received on Fri Sep 23 2016 - 18:03:08 BST
