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
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:
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
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
> on
behalf of Bob Simons - NOAA Federal
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
>
Date: Thursday,
+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 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
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,
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
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
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
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
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
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
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
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
17 matches
Mail list logo