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:
T turns into
(no space between date and time, exceedingly less human
I have to disagree. Personally, I find the T a lot less readable than
separating them with a space.
On 9/22/16 4:04 PM, Armstrong, Edward M (398G) wrote:
> 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-met
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
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
mailto:cf-metadata-boun...@cgd.ucar.edu>> on
behalf of Bob Simons - NOAA Federal
mailto:bob.sim...@noaa.gov>>
Date: Thursday, September 22, 2016 at 2:14 P
Sorry I misspoke. A ‘Z’ is required to identify the ISO8601 time stamp as GMT
time. So I do agree with point #2 below….but adding a ‘Z’ seems to break the
CF convention up to this point.
From: JPL
mailto:edward.m.armstr...@jpl.nasa.gov>>
Date: Thursday, September 22, 2016 at 2:13 PM
To: Chris
+1 for the "T" in the time string.
On Thu, Sep 22, 2016 at 3:14 PM, Bob Simons - NOAA Federal <
bob.sim...@noaa.gov> 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
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 t
I think #1 is a great idea as it has been a practice in a number of satellite
missions.
#2 I am not too fond of. Best practice says that when offset is not specified
implicitly GMT must be assumed. So I think specifying a ‘Z’ in ISO time stamp
is only necessary when specifying a non zero offse
Centers for Environmental Information
> > <http://ncdc.noaa.gov/>
> > *formerly NOAA?s National Climatic Data Center*
> > 151 Patton Ave, Asheville, NC 28801
> > e: jbi...@cicsnc.org
> > o: +1 828 271 4900
> >
> > *Connect with us on Facebook for clim
On Thu, Sep 22, 2016 at 12:06 PM, Jim Biard wrote:
> So I went and dug into the source code for UDUNITS and UDUNITS-2. Both
> versions of UDUNITS allow a wide variety of epoch date/time formulations
> with and without space delimiters between just about any of the components,
> with and without l
Hi.
So I went and dug into the source code for UDUNITS and UDUNITS-2. Both
versions of UDUNITS allow a wide variety of epoch date/time formulations
with and without space delimiters between just about any of the
components, with and without leading zeros, with and without a 'T'
between the da
Hi all,
Just a quick note on Chris' CF 2 question (until I have a bit more time to
think more fully on this discussion) ...
The EC netCDF-CF project that Ben mentioned is working on a number of CF
extension efforts that are looking to use features of the netCDF enhanced
data model. Those efforts
On Thu, Sep 22, 2016 at 9:26 AM, Jonathan Gregory wrote:
> I didn't suggest parsing attribute strings. The same numbers that Ben
> would put
> in his x and y auxiliary coordinate variables for a single polygon can
> appear
> in coordinate bounds variables according to the existing convention.
O
Dear Chris
> > If the regions were irregular
> > polygons in latitude and longitude, nv would be the number of vertices and
> > the
> > lat and lon bounds would trace the outline of the polygon e.g. nv=3,
> > lat=0,90,0
> > and lon=0,0,90 describes the eighth of the sphere which is bounded by the
On Thu, Sep 22, 2016 at 9:45 AM, Chris Barker wrote:
> I think UDUnits does not use a T but maybe it will accept it.
>
UDUNITS accepts the "T" and can print it.
Regards,
Steve Emmerson
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mail
Sorry, not enough time to really read tis all carefully, but a couple
comments from a brief look:
>
> If the regions were irregular
> polygons in latitude and longitude, nv would be the number of vertices and
> the
> lat and lon bounds would trace the outline of the polygon e.g. nv=3,
> lat=0,90,0
On Thu, Sep 22, 2016 at 5:53 AM, Jonathan Gregory wrote:
> Dear Chris et al.
>
> I may have missed it - are you proposing a change or a clarification to the
> text of the CF standard document?
>
yes and no:
Yes, in that I'm proposing that somthing be chaged in the docuemnt --
really about recom
Dear Jonathan,
I can’t speak to the technical details, but can mention some motivation for
simple geometries. Among other applications, NetCDF-CF is now being used as an
intermediate & output data format in the US National Weather Service’s National
Water Model (NWM). This forecasts streamflow
Dear Chris et al.
I may have missed it - are you proposing a change or a clarification to the
text of the CF standard document?
Best wishes and thanks
Jonathan
- Forwarded message from Chris Barker -
> Date: Wed, 21 Sep 2016 12:52:48 -0700
> From: Chris Barker
> To: Nan Galbraith
>
Dear Ben
Thank you for your thoughtful and interesting proposal. I have quite a lot of
questions and comments about it.
* You explain that the need is to specify spatial coordinates with a simple
geometry for a timeSeries variable. For example, this could be for the
discharge as a function of tim
Hi Chris,
One time zone label (Z for UT) is valid in 8601.
In SeaDataNet we took the decision some 10 years back to 'profile' ISO8601 by
disallowing any character to the right of the seconds and defining the result
as UT. The reason this was done was to prevent data delivery in local time wit
21 matches
Mail list logo