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-request at cgd.ucar.edu> wrote:
> Send CF-metadata mailing list submissions to
> cf-metadata at 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-request at cgd.ucar.edu
>
> You can reach the person managing the list at
> cf-metadata-owner at 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.barker at noaa.gov>
> To: Jim Biard <jbiard at cicsnc.org>
> 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
> Message-ID:
> <CALGmxEJoWkZ=-_AwA-d=AH-x9t1o+u9AgaMHtMKSXRkaaEpgwg_at_
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Sep 22, 2016 at 12:06 PM, Jim Biard <jbiard at 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.barker at 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-metadata at 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: jbiard at 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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
> > _at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. *
> >
> > _______________________________________________
> > 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
> -------------- 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20160922/6dbedc9e/attachment.html>
Received on Thu Sep 22 2016 - 15:11:43 BST
