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-0001.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-0001.png>
Received on Thu Sep 22 2016 - 14:54:04 BST
