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

[Little, Chris]

Jim and Chris B,

I would like to weigh in here, please?

Adhering to UDUnits has merits, but once one adopts ISO8601-like notations, as there is no way of specifying otherwise, people assume it *is* ISO8601 and therefore a string without a time zone marker indicates local time (whatever that is - Solar? Mean Solar? Sidereal? National legal?)

There is work just starting in the OGC/ISO pipeline on how to indicate a non-Gregorian calendar using ISO8601 like notation, for the WKT communities.

Personally, I would advocate ISO8601 strict adherence, as most of the recommended best practices and profiles, such as RFC3339, are generally strict subsets of ISO 8601.

Chris


-----Original Message-----
From: CF-metadata [mailto:cf-metadata-***@cgd.ucar.edu] On Behalf Of cf-metadata-***@cgd.ucar.edu
Sent: Wednesday, September 14, 2016 10:02 PM
To: cf-***@cgd.ucar.edu
Subject: CF-metadata Digest, Vol 161, Issue 3

Send CF-metadata mailing list submissions to
cf-***@cgd.ucar.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
or, via email, send a message with subject or body 'help' to
cf-metadata-***@cgd.ucar.edu

You can reach the person managing the list at
cf-metadata-***@cgd.ucar.edu

When replying, please edit your Subject line so it is more specific than "Re: Contents of CF-metadata digest..."


Today's Topics:

1. nitpick in time axes example (Chris Barker)
2. Re: nitpick in time axes example (Jim Biard)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Sep 2016 12:34:11 -0700
From: Chris Barker <***@noaa.gov>
To: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
Subject: [CF-metadata] nitpick in time axes example
Message-ID:
<CALGmxE+S80kd1CnD-55btZZhz=Vko-bbbpS-Bv2w2a-***@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I see in teh doc:

Example 4.4. Time axis

double time(time) ;
time:long_name = "time" ;
time:units = "days since 1990-1-1 0:0:0" ;

IIUC, ISO 8601 requires two digits for the time pieces [1], so that should
be:

"days since 1990-1-1 00:00:00"


The parser I use isn't picky about this, but maybe some are?

BTW, as it's an example, we should probably throw a time offset on there,
too:

"days since 1990-1-1 00:00:00Z"


or

"days since 1990-1-1 00:00:00+00:00"


[1] at least according to wikipedia:
https://en.wikipedia.org/wiki/ISO_8601#Times


-Chris


--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160914/614bb5f3/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 14 Sep 2016 17:01:34 -0400
From: Jim Biard <***@cicsnc.org>
To: cf-***@cgd.ucar.edu
Subject: Re: [CF-metadata] nitpick in time axes example
Message-ID: <88f473d3-243e-0219-cfa8-***@cicsnc.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Chris,

CF has consistently maintained adherence to the UDUNITS definition for the reference time string, and that is different from ISO. (See CF Section 4.4
<http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#time-coordinate>)
As stated at the top of the section, Z is not used in the case of UTC and there is a space before any time zone offset. Example 4.4 is written that way specifically to make it clear that single-digit numbers are legal.

Grace and peace,

Jim


On 9/14/16 3:34 PM, Chris Barker wrote:
> I see in teh doc:
>
> Example 4.4. Time axis
> double time(time) ;
> time:long_name = "time" ;
> time:units = "days since 1990-1-1 0:0:0" ; IIUC, ISO 8601 requires
> two digits for the time pieces [1], so that should be:
>
> "days since 1990-1-1 00:00:00"
>
> The parser I use isn't picky about this, but maybe some are?
>
> BTW, as it's an example, we should probably throw a time offset on
> there, too:
>
> "days since 1990-1-1 00:00:00Z"
>
> or
>
> "days since 1990-1-1 00:00:00+00:00"
>
> [1] at least according to wikipedia:
> https://en.wikipedia.org/wiki/ISO_8601#Times
>
>
> -Chris
>
>
> --
>
> 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 <mailto:***@noaa.gov>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA?s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: ***@cicsnc.org <mailto:***@cicsnc.org>
o: [phone]

/Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160914/8af43717/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160914/8af43717/attachment.png>

------------------------------

Subject: Digest Footer

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


------------------------------

End of CF-metadata Digest, Vol 161, Issue 3
*******************************************

[Jim Biard]

Chris,

That's a completely valid suggestion. We have to consider implications
for backwards compatibility. Among other things, UDUNITS would need to
change their convention, since CF follows UDUNITS in this matter, as
with all other units. There's nothing that says we can't make changes. I
was explaining the "is" as opposed to the "could be" with time units.

Grace and peace,

Jim


On 9/15/16 7:26 AM, Little, Chris wrote:
> Jim and Chris B,
>
> I would like to weigh in here, please?
>
> Adhering to UDUnits has merits, but once one adopts ISO8601-like notations, as there is no way of specifying otherwise, people assume it *is* ISO8601 and therefore a string without a time zone marker indicates local time (whatever that is - Solar? Mean Solar? Sidereal? National legal?)
>
> There is work just starting in the OGC/ISO pipeline on how to indicate a non-Gregorian calendar using ISO8601 like notation, for the WKT communities.
>
> Personally, I would advocate ISO8601 strict adherence, as most of the recommended best practices and profiles, such as RFC3339, are generally strict subsets of ISO 8601.
>
> Chris
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-***@cgd.ucar.edu] On Behalf Of cf-metadata-***@cgd.ucar.edu
> Sent: Wednesday, September 14, 2016 10:02 PM
> To: cf-***@cgd.ucar.edu
> Subject: CF-metadata Digest, Vol 161, Issue 3
>
> Send CF-metadata mailing list submissions to
> cf-***@cgd.ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> or, via email, send a message with subject or body 'help' to
> cf-metadata-***@cgd.ucar.edu
>
> You can reach the person managing the list at
> cf-metadata-***@cgd.ucar.edu
>
> When replying, please edit your Subject line so it is more specific than "Re: Contents of CF-metadata digest..."
>
>
> Today's Topics:
>
> 1. nitpick in time axes example (Chris Barker)
> 2. Re: nitpick in time axes example (Jim Biard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Sep 2016 12:34:11 -0700
> From: Chris Barker <***@noaa.gov>
> To: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
> Subject: [CF-metadata] nitpick in time axes example
> Message-ID:
> <CALGmxE+S80kd1CnD-55btZZhz=Vko-bbbpS-Bv2w2a-***@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I see in teh doc:
>
> Example 4.4. Time axis
>
> double time(time) ;
> time:long_name = "time" ;
> time:units = "days since 1990-1-1 0:0:0" ;
>
> IIUC, ISO 8601 requires two digits for the time pieces [1], so that should
> be:
>
> "days since 1990-1-1 00:00:00"
>
>
> The parser I use isn't picky about this, but maybe some are?
>
> BTW, as it's an example, we should probably throw a time offset on there,
> too:
>
> "days since 1990-1-1 00:00:00Z"
>
>
> or
>
> "days since 1990-1-1 00:00:00+00:00"
>
>
> [1] at least according to wikipedia:
> https://en.wikipedia.org/wiki/ISO_8601#Times
>
>
> -Chris
>
>

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: ***@cicsnc.org <mailto:***@cicsnc.org>
o: [phone]

/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

[Steve Emmerson]

Just FYI, the UDUNITS-2 package accepts ISO 8601-compliant timestamps like
the following:

2016-01-01T05:04:03-0600

2016-01-01T05:04:03Z


Regards,
Steve Emmerson

[Chris Barker]

On Thu, Sep 15, 2016 at 5:40 AM, Jim Biard <***@cicsnc.org> wrote:

> That's a completely valid suggestion. We have to consider implications for
> backwards compatibility. Among other things, UDUNITS would need to change
> their convention, since CF follows UDUNITS in this matter, as with all
> other units.
>
As long as UDUNITS accepts ISO-compliant strings, then we're good. And it
looks like it does.

> There's nothing that says we can't make changes. I was explaining the "is"
> as opposed to the "could be" with time units.
>
The only change I would suggest at the moment would be to "prefer"
ISO-complienat time strings, and therefore use them in the examples.

-CHB



> Grace and peace,
>
> Jim
>
> On 9/15/16 7:26 AM, Little, Chris wrote:
>
> Jim and Chris B,
>
> I would like to weigh in here, please?
>
> Adhering to UDUnits has merits, but once one adopts ISO8601-like notations, as there is no way of specifying otherwise, people assume it *is* ISO8601 and therefore a string without a time zone marker indicates local time (whatever that is - Solar? Mean Solar? Sidereal? National legal?)
>
> There is work just starting in the OGC/ISO pipeline on how to indicate a non-Gregorian calendar using ISO8601 like notation, for the WKT communities.
>
> Personally, I would advocate ISO8601 strict adherence, as most of the recommended best practices and profiles, such as RFC3339, are generally strict subsets of ISO 8601.
>
> Chris
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-***@cgd.ucar.edu <cf-metadata-***@cgd.ucar.edu>] On Behalf Of cf-metadata-***@cgd.ucar.edu
> Sent: Wednesday, September 14, 2016 10:02 PM
> To: cf-***@cgd.ucar.edu
> Subject: CF-metadata Digest, Vol 161, Issue 3
>
> Send CF-metadata mailing list submissions to
> cf-***@cgd.ucar.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> or, via email, send a message with subject or body 'help' to
> cf-metadata-***@cgd.ucar.edu
>
> You can reach the person managing the list at
> cf-metadata-***@cgd.ucar.edu
>
> When replying, please edit your Subject line so it is more specific than "Re: Contents of CF-metadata digest..."
>
>
> Today's Topics:
>
> 1. nitpick in time axes example (Chris Barker)
> 2. Re: nitpick in time axes example (Jim Biard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Sep 2016 12:34:11 -0700
> From: Chris Barker <***@noaa.gov> <***@noaa.gov>
> To: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu> <cf-***@cgd.ucar.edu> <cf-***@cgd.ucar.edu>
> Subject: [CF-metadata] nitpick in time axes example
> Message-ID:
> <CALGmxE+S80kd1CnD-55btZZhz=Vko-bbbpS-Bv2w2a-***@mail.gmail.com> <CALGmxE+S80kd1CnD-55btZZhz=Vko-bbbpS-Bv2w2a-***@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I see in teh doc:
>
> Example 4.4. Time axis
>
> double time(time) ;
> time:long_name = "time" ;
> time:units = "days since 1990-1-1 0:0:0" ;
>
> IIUC, ISO 8601 requires two digits for the time pieces [1], so that should
> be:
>
> "days since 1990-1-1 00:00:00"
>
>
> The parser I use isn't picky about this, but maybe some are?
>
> BTW, as it's an example, we should probably throw a time offset on there,
> too:
>
> "days since 1990-1-1 00:00:00Z"
>
>
> or
>
> "days since 1990-1-1 00:00:00+00:00"
>
>
> [1] at least according to wikipedia:https://en.wikipedia.org/wiki/ISO_8601#Times
>
>
> -Chris
>
>
>
>
> --
> [image: CICS-NC] <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information
> <http://ncdc.noaa.gov/>
> *formerly NOAA’s National Climatic Data Center*
> 151 Patton Ave, Asheville, NC 28801
> e: ***@cicsnc.org
> o: [phone]
>
> *Connect with us on Facebook for climate
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
> Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
> @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. *
>
> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>


--

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

[Nan Galbraith]

Can we recommend the use of ISO-compatible date strings, with
the caveat that time zone should always be included?

It's unfortunate that ISO defaults to local time, and that seems to be
non-negotiable.

This is what we use in the OceanSITES implementation of CF. Obviously,
it won't solve everyone's needs, but it's perfectly good for in situ data.

Regards - Nan

On 9/15/16 3:10 PM, Chris Barker wrote:
> On Thu, Sep 15, 2016 at 5:40 AM, Jim Biard wrote: > > That's a completely valid suggestion. We have to consider >
implications for backwards compatibility. Among other things, UDUNITS >
would need to change their convention, since CF follows UDUNITS in >
this matter, as with all other units. > > As long as UDUNITS accepts
ISO-compliant strings, then we're good. > And it looks like it does. > >
There's nothing that says we can't make changes. I was explaining the >
"is" as opposed to the "could be" with time units. > > The only change I
would suggest at the moment would be to "prefer" > ISO-complienat time
strings, and therefore use them in the examples. > > -CHB > > Grace and
peace, > > Jim > > > On 9/15/16 7:26 AM, Little, Chris wrote: >> Jim and
Chris B, I would like to weigh in here, please? Adhering to >> UDUnits
has merits, but once one adopts ISO8601-like notations, as >> there is
no way of specifying otherwise, people assume it *is* >> ISO8601 and
therefore a string without a time zone marker indicates >> local time
(whatever that is - Solar? Mean Solar? Sidereal? >> National legal?)
There is work just starting in the OGC/ISO >> pipeline on how to
indicate a non-Gregorian calendar using ISO8601 >> like notation, for
the WKT communities. Personally, I would >> advocate ISO8601 strict
adherence, as most of the recommended best >> practices and profiles,
such as RFC3339, are generally strict >> subsets of ISO 8601. Chris >>
>> -----Original Message----- From: CF-metadata >> Sent: Wednesday, >>
September 14, 2016 10:02 PM >> Subject: CF-metadata Digest, Vol 161,
Issue 3 >> >> Today's Topics: >> >> 1. nitpick in time axes example
(Chris Barker) 2. Re: nitpick in >> time axes example (Jim Biard) >> >>
>>
----------------------------------------------------------------------
>> >> >>
Message: 1
>> Date: Wed, 14 Sep 2016 12:34:11 -0700 >> From: Chris Barker<***@noaa.gov> >> To:
"cf-***@cgd.ucar.edu" >> Subject: [CF-metadata] nitpick in time
axes example >> >> I see in teh doc: >> >> Example 4.4. Time axis >> >>
double time(time) ; time:long_name = "time" ; time:units = "days >>
since 1990-1-1 0:0:0" ; >> >> IIUC, ISO 8601 requires two digits for the
time pieces [1], so that >> should be: >> >> "days since 1990-1-1
00:00:00" >> >> >> The parser I use isn't picky about this, but maybe
some are? >> >> BTW, as it's an example, we should probably throw a time
offset on >> there, too: >> >> "days since 1990-1-1 00:00:00Z" >> >> >>
or >> >> "days since 1990-1-1 00:00:00+00:00" >> >> >> [1] at least
according to wikipedia: >> https://en.wikipedia.org/wiki/ISO_8601#Times
>> <https://en.wikipedia.org/wiki/ISO_8601#Times> >> >> >> -Chris


--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 [phone] *
*******************************************************

[Chris Barker]

On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu> wrote:

> Can we recommend the use of ISO-compatible date strings, with
> the caveat that time zone should always be included?
>

Yes, we really should do that (though it's an offset that is specified, not
a time zone)

It's unfortunate that ISO defaults to local time, and that seems to be
> non-negotiable.
>

yup :-(

This is what we use in the OceanSITES implementation of CF. Obviously,
> it won't solve everyone's needs,


I'm trying to see whos needs it wouldn't suit folks may well want local
time, rather than UTC, but having it be unspecified does no one any good.

and specifying times in "true" local time, with DST baked in is simply a
nightmare for everyone --- it really, really should be discouraged!

-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

[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 with embedded corrections thereby simplify application development. In retrospect it would have been better to mandate a 'Z', but hindsight is a wonderful thing and this practice is now encoded in millions of physical files and so difficult to fix.


Cheers, Roy.


Please note that I partially retired on 01/11/2015. I am now only working 7.5 hours a week and can only guarantee e-mail response on Wednesdays, my day in the office. All vocabulary queries should be sent to ***@bodc.ac.uk. Please also use this e-mail if your requirement is urgent.


________________________________
From: CF-metadata <cf-metadata-***@cgd.ucar.edu> on behalf of Chris Barker <***@noaa.gov>
Sent: 21 September 2016 20:52
To: Nan Galbraith
Cc: cf-***@cgd.ucar.edu
Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu<mailto:***@whoi.edu>> wrote:
Can we recommend the use of ISO-compatible date strings, with
the caveat that time zone should always be included?

Yes, we really should do that (though it's an offset that is specified, not a time zone)

It's unfortunate that ISO defaults to local time, and that seems to be
non-negotiable.

yup :-(

This is what we use in the OceanSITES implementation of CF. Obviously,
it won't solve everyone's needs,

I'm trying to see whos needs it wouldn't suit folks may well want local time, rather than UTC, but having it be unspecified does no one any good.

and specifying times in "true" local time, with DST baked in is simply a nightmare for everyone --- it really, really should be discouraged!

-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<mailto:***@noaa.gov>
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________

[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 <***@noaa.gov> -----

> Date: Wed, 21 Sep 2016 12:52:48 -0700
> From: Chris Barker <***@noaa.gov>
> To: Nan Galbraith <***@whoi.edu>
> CC: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol
> 161, Issue 3
>
> On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu> wrote:
>
> > Can we recommend the use of ISO-compatible date strings, with
> > the caveat that time zone should always be included?
> >
>
> Yes, we really should do that (though it's an offset that is specified, not
> a time zone)
>
> It's unfortunate that ISO defaults to local time, and that seems to be
> > non-negotiable.
> >
>
> yup :-(
>
> This is what we use in the OceanSITES implementation of CF. Obviously,
> > it won't solve everyone's needs,
>
>
> I'm trying to see whos needs it wouldn't suit folks may well want local
> time, rather than UTC, but having it be unspecified does no one any good.
>
> and specifying times in "true" local time, with DST baked in is simply a
> nightmare for everyone --- it really, really should be discouraged!
>
> -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

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


----- End forwarded message -----

[Chris Barker]

On Thu, Sep 22, 2016 at 5:53 AM, Jonathan Gregory <***@reading.ac.uk
> 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 recommendations and example,s rather than chanign anything
about what it allowed.

No, in that I (or anyone else) has not proposed any particular text.

But if there seems to be a consensus that it would be good ti updated the
docs to make these recommendaiont,s than hopefully someone will suggest
actual text. (I'm short of roundtoits at the moment).

I think these are the ideas:

1) recommend ISO-8601 compliant time strings

2) recommend that an offset (or 'Z') always be provided in a time string.

3) Have all examples conform to the above.

Does anyone this these are NOT good ideas?


NOTE: as I understand it, ISO-8601 time strings are acceptable to UDUnits,
and thus this would not be a change to the standard in any way -- simply
recommendations of good practice.

TBD: According to wikipedia, ISO requires a "T" in between teh date and
time, but then says " It is permitted to omit the 'T' character by mutual
agreement" so do we want to recommend one or the other? I think UDUnits
does not use a T but maybe it will accept it. (the Python netcdf4 lib added
support for the optional "T" a couple years ago -- no idea about any other
parsing libs.


-CHB




> Best wishes and thanks
>
> Jonathan
>
> ----- Forwarded message from Chris Barker <***@noaa.gov> -----
>
> > Date: Wed, 21 Sep 2016 12:52:48 -0700
> > From: Chris Barker <***@noaa.gov>
> > To: Nan Galbraith <***@whoi.edu>
> > CC: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
> > Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest,
> Vol
> > 161, Issue 3
> >
> > On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu>
> wrote:
> >
> > > Can we recommend the use of ISO-compatible date strings, with
> > > the caveat that time zone should always be included?
> > >
> >
> > Yes, we really should do that (though it's an offset that is specified,
> not
> > a time zone)
> >
> > It's unfortunate that ISO defaults to local time, and that seems to be
> > > non-negotiable.
> > >
> >
> > yup :-(
> >
> > This is what we use in the OceanSITES implementation of CF. Obviously,
> > > it won't solve everyone's needs,
> >
> >
> > I'm trying to see whos needs it wouldn't suit folks may well want local
> > time, rather than UTC, but having it be unspecified does no one any good.
> >
> > and specifying times in "true" local time, with DST baked in is simply a
> > nightmare for everyone --- it really, really should be discouraged!
> >
> > -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
>
> > _______________________________________________
> > CF-metadata mailing list
> > CF-***@cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>



--

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

[Steve Emmerson]

On Thu, Sep 22, 2016 at 9:45 AM, Chris Barker <***@noaa.gov> 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

[Jim Biard]

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 date and the time, and allowing 'UTC', 'GMT', or 'Z' (in
addition to the 'classical' YYYY-MM-DD hh:mm:ss[.sss] [-]h:mm form).

So on one level this seems like a case for modifying the documentation
without a formal change to the convention. Except...

The CF time convention is out there already with the pretty well
understood classical form that I mentioned above. Software written to
that form could very well break if a different form is used. In
addition, there is an issue that connects with all of this that I've
been horribly slow to write a ticket on. It has to do with time systems
other than UTC, such as native GPS and TAI, that don't have leap seconds.

At the very minimum, we need to make it very clear that times without
offsets or designators ARE NOT local times. This is baked deeply enough
into CF and existing data sets that I don't see any clean way to go with
ISO8061.

This leads me to think that any change should be considered a change to
the time convention, not just a document edit.

Grace and peace,

Jim

On 9/22/16 12:23 PM, Steve Emmerson wrote:
> On Thu, Sep 22, 2016 at 9:45 AM, Chris Barker <***@noaa.gov
> <mailto:***@noaa.gov>> 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-***@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: ***@cicsnc.org <mailto:***@cicsnc.org>
o: [phone]

/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

[Chris Barker]

On Thu, Sep 22, 2016 at 12:06 PM, Jim Biard <***@cicsnc.org> 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 leading zeros, with and without a 'T' between the date and
> the time, and allowing 'UTC', 'GMT', or 'Z' (in addition to the 'classical'
> YYYY-MM-DD hh:mm:ss[.sss] [-]h:mm form).
>
>
Thanks! so UDUNITS is quite flexible -- make this easier :-)

> So on one level this seems like a case for modifying the documentation
> without a formal change to the convention. Except...
>
> The CF time convention is out there already with the pretty well
> understood classical form that I mentioned above.
>
Isn't the "classical" form ISO8601 without the "T" ?

> Software written to that form could very well break if a different form is
> used.
>
well, the spec says UDUnits, so it's up to the software to fix itself :-)
IN any case, I know I"ve seen files that claim to be CF compliant both with
and without the "T" -- and, in fact, we had to update the python lib a
couple years ago to accommodate the "T". But if we are sure that the no T
version is the most common, then whe can make that the official
recommendation -- it does seem to be ISO compliant a swell.

In addition, there is an issue that connects with all of this that I've
> been horribly slow to write a ticket on. It has to do with time systems
> other than UTC, such as native GPS and TAI, that don't have leap seconds.
>
yeah, that's a mess, but a distinct issue, yes?

At the very minimum, we need to make it very clear that times without
> offsets or designators ARE NOT local times. This is baked deeply enough
> into CF and existing data sets that I don't see any clean way to go with
> ISO8061.
>
This is in the docs now:

*Note: if the time zone is omitted the default is UTC, and if both time and
time zone are omitted the default is 00:00:00 UTC.*

Which is unfortunate. But it's been there "forever", yes? It does mean that
there is no way in CF to specify local time, but that may be a good thing.
"local time" is a really poorly defined concept. I don't have the official
ISO docs, but the wikipedia page doesn't define it.

In other contexts (at least the Python datetime world) the concept "naive
time" is used. what this means is that you have no idea what time zone it
is, but it behaves as UTC (i.e. no DST). It's up to the app to know what
time zone it is dealing with. I think that's what an ISO8601 string with no
offset really is.

But CF says it's UTC, so it's UTC.

But we don't have to actually recommend that anyone use that, or show it in
any examples.

Are we converging on ISO8601 without the "T", and always with an offset or
"Z" as the recommended way to express datetimes in CF?

-CHB




> This leads me to think that any change should be considered a change to
> the time convention, not just a document edit.
>
> Grace and peace,
>
> Jim
> On 9/22/16 12:23 PM, Steve Emmerson wrote:
>
> On Thu, Sep 22, 2016 at 9:45 AM, Chris Barker <***@noaa.gov>
> 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 listCF-***@cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --
> [image: CICS-NC] <http://www.cicsnc.org/> Visit us on
> Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA National Centers for Environmental Information
> <http://ncdc.noaa.gov/>
> *formerly NOAA’s National Climatic Data Center*
> 151 Patton Ave, Asheville, NC 28801
> e: ***@cicsnc.org
> o: [phone]
>
> *Connect with us on Facebook for climate
> <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
> <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
> Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
> @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. *
>
> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>


--

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

[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 offset.

From: CF-metadata <cf-metadata-***@cgd.ucar.edu<mailto:cf-metadata-***@cgd.ucar.edu>> on behalf of Chris Barker <***@noaa.gov<mailto:***@noaa.gov>>
Date: Thursday, September 22, 2016 at 8:45 AM
To: Jonathan Gregory <***@reading.ac.uk<mailto:***@reading.ac.uk>>
Cc: "cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>" <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

On Thu, Sep 22, 2016 at 5:53 AM, Jonathan Gregory <***@reading.ac.uk<mailto:***@reading.ac.uk>> 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 recommendations and example,s rather than chanign anything about what it allowed.

No, in that I (or anyone else) has not proposed any particular text.

But if there seems to be a consensus that it would be good ti updated the docs to make these recommendaiont,s than hopefully someone will suggest actual text. (I'm short of roundtoits at the moment).

I think these are the ideas:

1) recommend ISO-8601 compliant time strings

2) recommend that an offset (or 'Z') always be provided in a time string.

3) Have all examples conform to the above.

Does anyone this these are NOT good ideas?


NOTE: as I understand it, ISO-8601 time strings are acceptable to UDUnits, and thus this would not be a change to the standard in any way -- simply recommendations of good practice.

TBD: According to wikipedia, ISO requires a "T" in between teh date and time, but then says " It is permitted to omit the 'T' character by mutual agreement" so do we want to recommend one or the other? I think UDUnits does not use a T but maybe it will accept it. (the Python netcdf4 lib added support for the optional "T" a couple years ago -- no idea about any other parsing libs.


-CHB



Best wishes and thanks

Jonathan

----- Forwarded message from Chris Barker <***@noaa.gov<mailto:***@noaa.gov>> -----

> Date: Wed, 21 Sep 2016 12:52:48 -0700
> From: Chris Barker <***@noaa.gov<mailto:***@noaa.gov>>
> To: Nan Galbraith <***@whoi.edu<mailto:***@whoi.edu>>
> CC: "cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>" <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol
> 161, Issue 3
>
> On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu<mailto:***@whoi.edu>> wrote:
>
> > Can we recommend the use of ISO-compatible date strings, with
> > the caveat that time zone should always be included?
> >
>
> Yes, we really should do that (though it's an offset that is specified, not
> a time zone)
>
> It's unfortunate that ISO defaults to local time, and that seems to be
> > non-negotiable.
> >
>
> yup :-(
>
> This is what we use in the OceanSITES implementation of CF. Obviously,
> > it won't solve everyone's needs,
>
>
> I'm trying to see whos needs it wouldn't suit folks may well want local
> time, rather than UTC, but having it be unspecified does no one any good.
>
> and specifying times in "true" local time, with DST baked in is simply a
> nightmare for everyone --- it really, really should be discouraged!
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R [phone]<tel:%28206%29%20526-6959> voice
> 7600 Sand Point Way NE [phone]<tel:%28206%29%20526-6329> fax
> Seattle, WA 98115 [phone]<tel:%28206%29%20526-6317> main reception
>
> ***@noaa.gov<mailto:***@noaa.gov>

> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu<mailto:CF-***@cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-***@cgd.ucar.edu<mailto:CF-***@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--

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<mailto:***@noaa.gov>

[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 <***@jpl.nasa.gov<mailto:***@jpl.nasa.gov>>
Date: Thursday, September 22, 2016 at 2:13 PM
To: Chris Barker <***@noaa.gov<mailto:***@noaa.gov>>, Jonathan Gregory <***@reading.ac.uk<mailto:***@reading.ac.uk>>
Cc: "cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>" <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

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 offset.

From: CF-metadata <cf-metadata-***@cgd.ucar.edu<mailto:cf-metadata-***@cgd.ucar.edu>> on behalf of Chris Barker <***@noaa.gov<mailto:***@noaa.gov>>
Date: Thursday, September 22, 2016 at 8:45 AM
To: Jonathan Gregory <***@reading.ac.uk<mailto:***@reading.ac.uk>>
Cc: "cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>" <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol 161, Issue 3

On Thu, Sep 22, 2016 at 5:53 AM, Jonathan Gregory <***@reading.ac.uk<mailto:***@reading.ac.uk>> 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 recommendations and example,s rather than chanign anything about what it allowed.

No, in that I (or anyone else) has not proposed any particular text.

But if there seems to be a consensus that it would be good ti updated the docs to make these recommendaiont,s than hopefully someone will suggest actual text. (I'm short of roundtoits at the moment).

I think these are the ideas:

1) recommend ISO-8601 compliant time strings

2) recommend that an offset (or 'Z') always be provided in a time string.

3) Have all examples conform to the above.

Does anyone this these are NOT good ideas?


NOTE: as I understand it, ISO-8601 time strings are acceptable to UDUnits, and thus this would not be a change to the standard in any way -- simply recommendations of good practice.

TBD: According to wikipedia, ISO requires a "T" in between teh date and time, but then says " It is permitted to omit the 'T' character by mutual agreement" so do we want to recommend one or the other? I think UDUnits does not use a T but maybe it will accept it. (the Python netcdf4 lib added support for the optional "T" a couple years ago -- no idea about any other parsing libs.


-CHB



Best wishes and thanks

Jonathan

----- Forwarded message from Chris Barker <***@noaa.gov<mailto:***@noaa.gov>> -----

> Date: Wed, 21 Sep 2016 12:52:48 -0700
> From: Chris Barker <***@noaa.gov<mailto:***@noaa.gov>>
> To: Nan Galbraith <***@whoi.edu<mailto:***@whoi.edu>>
> CC: "cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>" <cf-***@cgd.ucar.edu<mailto:cf-***@cgd.ucar.edu>>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest, Vol
> 161, Issue 3
>
> On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu<mailto:***@whoi.edu>> wrote:
>
> > Can we recommend the use of ISO-compatible date strings, with
> > the caveat that time zone should always be included?
> >
>
> Yes, we really should do that (though it's an offset that is specified, not
> a time zone)
>
> It's unfortunate that ISO defaults to local time, and that seems to be
> > non-negotiable.
> >
>
> yup :-(
>
> This is what we use in the OceanSITES implementation of CF. Obviously,
> > it won't solve everyone's needs,
>
>
> I'm trying to see whos needs it wouldn't suit folks may well want local
> time, rather than UTC, but having it be unspecified does no one any good.
>
> and specifying times in "true" local time, with DST baked in is simply a
> nightmare for everyone --- it really, really should be discouraged!
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R [phone]<tel:%28206%29%20526-6959> voice
> 7600 Sand Point Way NE [phone]<tel:%28206%29%20526-6329> fax
> Seattle, WA 98115 [phone]<tel:%28206%29%20526-6317> main reception
>
> ***@noaa.gov<mailto:***@noaa.gov>

> _______________________________________________
> CF-metadata mailing list
> CF-***@cgd.ucar.edu<mailto:CF-***@cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


----- End forwarded message -----
_______________________________________________
CF-metadata mailing list
CF-***@cgd.ucar.edu<mailto:CF-***@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--

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<mailto:***@noaa.gov>

[Chris Barker]

On Thu, Sep 22, 2016 at 3:00 PM, Armstrong, Edward M (398G) <
***@jpl.nasa.gov> wrote:

> Sorry I misspoke. A ‘Z’ is required to identify the ISO8601 time stamp as
> GMT time. So I do agree with point #2 below
.
>

exactly.


> but adding a ‘Z’ seems to break the CF convention up to this point.
>

it doesn't break the convention to add the Z -- but NOT adding a Z means
something different in CF than in other contexts, which sucks, but it's too
late to do anything about that.

So it's all the more important to definel using "Z" as best practice.

-CHB





> From: JPL <***@jpl.nasa.gov>
> Date: Thursday, September 22, 2016 at 2:13 PM
> To: Chris Barker <***@noaa.gov>, Jonathan Gregory <
> ***@reading.ac.uk>
>
> Cc: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest,
> Vol 161, Issue 3
>
> 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 offset.
>
> From: CF-metadata <cf-metadata-***@cgd.ucar.edu> on behalf of Chris
> Barker <***@noaa.gov>
> Date: Thursday, September 22, 2016 at 8:45 AM
> To: Jonathan Gregory <***@reading.ac.uk>
> Cc: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest,
> Vol 161, Issue 3
>
> On Thu, Sep 22, 2016 at 5:53 AM, Jonathan Gregory <
> ***@reading.ac.uk> 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 recommendations and example,s rather than chanign anything
> about what it allowed.
>
> No, in that I (or anyone else) has not proposed any particular text.
>
> But if there seems to be a consensus that it would be good ti updated the
> docs to make these recommendaiont,s than hopefully someone will suggest
> actual text. (I'm short of roundtoits at the moment).
>
> I think these are the ideas:
>
> 1) recommend ISO-8601 compliant time strings
>
> 2) recommend that an offset (or 'Z') always be provided in a time string.
>
> 3) Have all examples conform to the above.
>
> Does anyone this these are NOT good ideas?
>
>
> NOTE: as I understand it, ISO-8601 time strings are acceptable to UDUnits,
> and thus this would not be a change to the standard in any way -- simply
> recommendations of good practice.
>
> TBD: According to wikipedia, ISO requires a "T" in between teh date and
> time, but then says " It is permitted to omit the 'T' character by mutual
> agreement" so do we want to recommend one or the other? I think UDUnits
> does not use a T but maybe it will accept it. (the Python netcdf4 lib added
> support for the optional "T" a couple years ago -- no idea about any other
> parsing libs.
>
>
> -CHB
>
>
>
>
>> Best wishes and thanks
>>
>> Jonathan
>>
>> ----- Forwarded message from Chris Barker <***@noaa.gov> -----
>>
>> > Date: Wed, 21 Sep 2016 12:52:48 -0700
>> > From: Chris Barker <***@noaa.gov>
>> > To: Nan Galbraith <***@whoi.edu>
>> > CC: "cf-***@cgd.ucar.edu" <cf-***@cgd.ucar.edu>
>> > Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest,
>> Vol
>> > 161, Issue 3
>> >
>> > On Tue, Sep 20, 2016 at 5:45 AM, Nan Galbraith <***@whoi.edu>
>> wrote:
>> >
>> > > Can we recommend the use of ISO-compatible date strings, with
>> > > the caveat that time zone should always be included?
>> > >
>> >
>> > Yes, we really should do that (though it's an offset that is specified,
>> not
>> > a time zone)
>> >
>> > It's unfortunate that ISO defaults to local time, and that seems to be
>> > > non-negotiable.
>> > >
>> >
>> > yup :-(
>> >
>> > This is what we use in the OceanSITES implementation of CF. Obviously,
>> > > it won't solve everyone's needs,
>> >
>> >
>> > I'm trying to see whos needs it wouldn't suit folks may well want local
>> > time, rather than UTC, but having it be unspecified does no one any
>> good.
>> >
>> > and specifying times in "true" local time, with DST baked in is simply a
>> > nightmare for everyone --- it really, really should be discouraged!
>> >
>> > -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
>>
>> > _______________________________________________
>> > CF-metadata mailing list
>> > CF-***@cgd.ucar.edu
>> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> CF-metadata mailing list
>> CF-***@cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
>
>
> --
>
> 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
>



--

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