Re: [CF-metadata] Temporal nitpicks.

2016-09-22 Thread 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: T turns into (no space between date and time, exceedingly less

Re: [CF-metadata] Temporal nitpicks.

2016-09-22 Thread Seth McGinnis
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:

Re: [CF-metadata] Temporal nitpicks.

2016-09-22 Thread 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

Re: [CF-metadata] Temporal nitpicks.

2016-09-22 Thread 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 > on behalf of Bob Simons - NOAA Federal

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Armstrong, Edward M (398G)
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,

Re: [CF-metadata] Temporal nitpicks.

2016-09-22 Thread Sean Arms
+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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Armstrong, Edward M (398G)
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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Chris Barker
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,

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

2016-09-22 Thread Ethan Davis
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

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

2016-09-22 Thread Chris Barker
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

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

2016-09-22 Thread Jonathan Gregory
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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Steve Emmerson
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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Chris Barker
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

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

2016-09-22 Thread Arctur, David K
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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Jonathan Gregory
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

Re: [CF-metadata] Feedback requested on proposed CF Simple Geometries

2016-09-22 Thread Jonathan Gregory
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

Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

2016-09-22 Thread Lowry, Roy K.
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