Hi, Chris,

     In case you and others are not already aware the Internet Engineering
Task Force (IETF) RFC 3339: "Date and Time on the Internet: Timestamps,"
circa 2002, (see https://www.ietf.org/rfc/rfc3339.txt, especially Appendix
A) requires the "T."  This spec adheres to ISO 8601, but is more
restrictive.  Most date/time libraries can handle this fine.

Cordially,
Aaron

On Thu, Sep 22, 2016 at 2:54 PM, <cf-metadata-requ...@cgd.ucar.edu> wrote:

> Send CF-metadata mailing list submissions to
>         cf-metadata@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-requ...@cgd.ucar.edu
>
> You can reach the person managing the list at
>         cf-metadata-ow...@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. Re: Temporal nitpicks. Was: CF-metadata Digest, Vol 161,
>       Issue 3 (Chris Barker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Sep 2016 13:54:04 -0700
> From: Chris Barker <chris.bar...@noaa.gov>
> To: Jim Biard <jbi...@cicsnc.org>
> Cc: "cf-metadata@cgd.ucar.edu" <cf-metadata@cgd.ucar.edu>
> Subject: Re: [CF-metadata] Temporal nitpicks. Was: CF-metadata Digest,
>         Vol 161, Issue 3
> Message-ID:
>         <CALGmxEJoWkZ=-_AwA-d=AH-x9t1o+u9AgaMHtMKSXRkaaEpgwg@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Sep 22, 2016 at 12:06 PM, Jim Biard <jbi...@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 <chris.bar...@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-metad...@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: jbi...@cicsnc.org
> > o: +1 828 271 4900
> >
> > *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-metadata@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.bar...@noaa.gov
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/
> attachments/20160922/1c02f6bb/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/20160922/1c02f6bb/attachment.png>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ------------------------------
>
> End of CF-metadata Digest, Vol 161, Issue 12
> ********************************************
>



-- 
Aaron D. Sweeney, Ph. D.
Water Level Data Manager

Cooperative Institute for Research in Environmental Sciences (CIRES)
University of Colorado at Boulder
and
NOAA National Centers for Environmental Information
*formerly NOAA's National Geophysical Data Center*
325 Broadway, E/NE42
Boulder, CO 80305-3328

Phone: 303-497-4797, Fax: 303-497-6513

DISCLAIMER: The contents of this message are mine personally and do not
necessarily reflect any position of NOAA.
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to