I hesitate to support encouraging the use of the T because in my
experience, approximately 0% of existing NetCDF files have it.
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.
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.
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?
NA-CORDEX / NARCCAP Data Manager
Associate Scientist IV
IMAGe - CISL - NCAR
On 9/22/16 3:14 PM, Bob Simons - NOAA Federal wrote:
> I vote to encourage the use of the T between date and time.
> * The T is the official method to connect the date and the time in the
> various ISO 8601 standards, notably the ISO 8601:2004 "extended" format
> String. As long as we are encouraging a specific format, let's encourage
> the official one, not the one which might be "most common".
> * The T serves an important function: it indicates that a time follows
> the date. Otherwise, it is harder for software (and humans) to know if
> the subsequent information is a time or some other information.
> Bob Simons
> IT Specialist
> Environmental Research Division
> NOAA Southwest Fisheries Science Center
> 99 Pacific St., Suite 255A (New!)
> Monterey, CA 93940 (New!)
> Phone: (831)333-9878 (New!)
> Fax: (831)648-8440
> Email: bob.sim...@noaa.gov <mailto:bob.sim...@noaa.gov>
> The contents of this message are mine personally and
> do not necessarily reflect any position of the
> Government or the National Oceanic and Atmospheric Administration.
> <>< <>< <>< <>< <>< <>< <>< <>< <><
> CF-metadata mailing list
CF-metadata mailing list