[CF-metadata] Temporal nitpicks.

[Bob Simons - NOAA Federal]

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.
--
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
Email: ***@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.
<>< <>< <>< <>< <>< <>< <>< <>< <><

[Sean Arms]

+1 for the "T" in the time string.

On Thu, Sep 22, 2016 at 3:14 PM, Bob Simons - NOAA Federal <

Post by Bob Simons - NOAA Federal
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.
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Armstrong, Edward M (398G)]

Just making the time stamp more human readable is important so I too am in favor of a ’T’ to separate the date and time !

From: CF-metadata <cf-metadata-***@cgd.ucar.edu<mailto:cf-metadata-***@cgd.ucar.edu>> on behalf of Bob Simons - NOAA Federal <***@noaa.gov<mailto:***@noaa.gov>>
Date: Thursday, September 22, 2016 at 2:14 PM
To: CF Metadata <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
Subject: Re: [CF-metadata] Temporal nitpicks.

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.


--
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
Email: ***@noaa.gov<mailto:***@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.
<>< <>< <>< <>< <>< <>< <>< <>< <><

[Seth McGinnis]

I have to disagree. Personally, I find the T a lot less readable than
separating them with a space.

Post by Armstrong, Edward M (398G)
Just making the time stamp more human readable is important so I too am
in favor of a ’T’ to separate the date and time !
Date: Thursday, September 22, 2016 at 2:14 PM
Subject: Re: [CF-metadata] Temporal nitpicks.
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.
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Armstrong, Edward M (398G)]

Without the ¹T' the ISO compliance of the time stamp is in a gray area.

According to the wiki

https://en.wikipedia.org/wiki/ISO_8601


"It is permitted to omit the 'T' character by mutual agreement²

But then I would assume:

<date>T<time> turns into <date><time>


(no space between date and time, exceedingly less human readable)

On 9/22/16, 3:43 PM, "CF-metadata on behalf of Seth McGinnis"

Post by Seth McGinnis
I have to disagree. Personally, I find the T a lot less readable than
separating them with a space.

Post by Armstrong, Edward M (398G)
Just making the time stamp more human readable is important so I too am
in favor of a ¹T¹ to separate the date and time !
Date: Thursday, September 22, 2016 at 2:14 PM
Subject: Re: [CF-metadata] Temporal nitpicks.
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.
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Seth McGinnis]

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?

Yrs,

--Seth

----
Seth McGinnis
NA-CORDEX / NARCCAP Data Manager
Associate Scientist IV
IMAGe - CISL - NCAR
-----

Post by Bob Simons - NOAA Federal
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.
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Chris Barker]

Post by Seth McGinnis
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

Post by Seth McGinnis
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

Post by Seth McGinnis
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,

Post by Seth McGinnis
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

***@noaa.gov

[Ethan Davis]

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

Post by Seth McGinnis
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
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

Post by Seth McGinnis
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

Post by Seth McGinnis
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,

Post by Seth McGinnis
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Sean Arms]

Hi all,

NetCDF-Java has no issues with T or no T in an ISO time string.

Sean

Post by Ethan Davis
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

Post by Seth McGinnis
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
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

Post by Seth McGinnis
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

Post by Seth McGinnis
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,

Post by Seth McGinnis
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 [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception
_______________________________________________
CF-metadata mailing list
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

[Bob Simons - NOAA Federal]

Seth McGinnis said:
"I hesitate to support encouraging the use of the T because in my
experience, approximately 0% of existing NetCDF files have it."

a) We aren't advocating forbidding the older formats / saying that files
with those time formats will become invalid. This is a question of what we
should encourage. So the issue of what is in current files should be
irrelevant. Tons of .nc files have "days since 1-1-1" (which is a horrid
format). Just because a format is common is not a good reason to encourage
its use.

b) The CF community needs to respect (i.e., faithfully follow) other
standards, just as we ask people to respect our standard. Some in the CF
community might think that CF is a self-contained standard, but it isn't.
We rely on IEEE-754 for binary number formats, various charsets for
character encoding, the CRS Well Known Text Format, numerous calendar
standards, numerous projections, etc. These are all external standards that
we have included in CF simply by referencing them. We shouldn't slightly
modify any of these standards when we use them in .nc files. Similarly we
should cleanly adopt the ISO 8601:2004(E) standard format (with the T) for
date times. [Okay, it weakens my argument that ISO 8601 says that the T may
be omitted by mutual consent, but I think is is better for CF to recommend
the format that is clearly recommended by ISO 8601:2004(E) (i.e., with the
T).]
--
Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
Email: ***@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.
<>< <>< <>< <>< <>< <>< <>< <>< <><

[Ethan Davis]

I totally agree. Don't deprecate anything but definitely encourage ISO
8601:2004(E) with the caveat of requiring an offset-from-Z indicator.

Cheers,

Ethan

On Fri, Sep 23, 2016 at 9:38 AM, Bob Simons - NOAA Federal <

Post by Bob Simons - NOAA Federal
"I hesitate to support encouraging the use of the T because in my
experience, approximately 0% of existing NetCDF files have it."
a) We aren't advocating forbidding the older formats / saying that files
with those time formats will become invalid. This is a question of what we
should encourage. So the issue of what is in current files should be
irrelevant. Tons of .nc files have "days since 1-1-1" (which is a horrid
format). Just because a format is common is not a good reason to encourage
its use.
b) The CF community needs to respect (i.e., faithfully follow) other
standards, just as we ask people to respect our standard. Some in the CF
community might think that CF is a self-contained standard, but it isn't.
We rely on IEEE-754 for binary number formats, various charsets for
character encoding, the CRS Well Known Text Format, numerous calendar
standards, numerous projections, etc. These are all external standards that
we have included in CF simply by referencing them. We shouldn't slightly
modify any of these standards when we use them in .nc files. Similarly we
should cleanly adopt the ISO 8601:2004(E) standard format (with the T) for
date times. [Okay, it weakens my argument that ISO 8601 says that the T may
be omitted by mutual consent, but I think is is better for CF to recommend
the format that is clearly recommended by ISO 8601:2004(E) (i.e., with the
T).]
--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: [phone] (New!)
Fax: [phone]
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
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata