On Thu, Sep 22, 2016 at 3:00 PM, Armstrong, Edward M (398G) <
Edward.M.Armstrong at 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 <edward.m.armstrong at jpl.nasa.gov>
> Date: Thursday, September 22, 2016 at 2:13 PM
> To: Chris Barker <chris.barker at noaa.gov>, Jonathan Gregory <
> j.m.gregory at reading.ac.uk>
>
> Cc: "cf-metadata at cgd.ucar.edu" <cf-metadata at 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-bounces at cgd.ucar.edu> on behalf of Chris
> Barker <chris.barker at noaa.gov>
> Date: Thursday, September 22, 2016 at 8:45 AM
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> Cc: "cf-metadata at cgd.ucar.edu" <cf-metadata at 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 <
> j.m.gregory at 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 <chris.barker at noaa.gov> -----
>>
>> > Date: Wed, 21 Sep 2016 12:52:48 -0700
>> > From: Chris Barker <chris.barker at noaa.gov>
>> > To: Nan Galbraith <ngalbraith at whoi.edu>
>> > CC: "cf-metadata at cgd.ucar.edu" <cf-metadata at 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 <ngalbraith at 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 (206) 526-6959 voice
>> > 7600 Sand Point Way NE (206) 526-6329 fax
>> > Seattle, WA 98115 (206) 526-6317 main reception
>> >
>> > Chris.Barker at noaa.gov
>>
>> > _______________________________________________
>> > CF-metadata mailing list
>> > CF-metadata at cgd.ucar.edu
>> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chris.Barker at noaa.gov
>
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160923/c3917862/attachment.html>
Received on Fri Sep 23 2016 - 13:09:11 BST
