Julien,
The general understanding, as far as I am aware, of how to read Section
4.4 "Time Coordinate" in the CF Conventions is that the format for the
units attribute is
<interval> since YYYY-MM-DD [HH:MM:SS[.n...]] [+/-HH:MM]
where the '[]' indicate optional elements. (And, yes, there are
variations, but this is the basic form.) I believe the intent of the
statements about defaults is to say that omission of a time zone offset
is to be interpreted as time counted at 0 degrees longitude. UTC is used
in the text as a shorthand, but as our discussion has brought out, it
wasn't really intended to indicate Coordinated Universal Time with its
full set of implications about leap seconds, etc.
You have to be careful about using the udunits2 app to determine intent,
since it was not available when this section was written. If you use the
older udunits app, you will find that it accepts any random set of
characters after the time and just passes them through. (I specified an
input time unit of "hours since 2001-02-04 00:00:00 dog", and it was
fine with it.) If that set of characters is a time offset like -03:00,
it will include that in the calculations. udunits2 has been expanded to
recognize both UTC and GMT and treat them as synonyms for +00:00, but
there's nothing in the CF documentation that indicates that a symbolic
time zone offset is expected or allowed.
Notice too that the udunits API documentation strongly encourages people
*not* to use the udunits or udunits2 package to handle time.
Grace and peace,
Jim
On 4/30/15 6:28 PM, Julien Demaria wrote:
>
> Jim,
>
> Are you sure that the units attribute cannot have "UTC" in it?
>
> CF specifies that a time zone may be represented in a time string like
> the "-6:00" in:
>
> "seconds since 1992-10-8 15:15:42.5 -6:00"
>
> and CF also says:
>
> 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.
>
> and it seems that the trailing ?UTC? string is accepted by udunits and
> is present in the canonical form:
>
> $ udunits2
>
> You have: microseconds since 2000-01-01 00:00:00 UTC
>
> You want:
>
> (1e-06 s) _at_ 20000101T000000.000000000 UTC
>
> Thanks,
>
> Julien
>
> >Jim Biard jbiard at cicsnc.org
>
> >Fri Apr 24 11:07:15 MDT 2015
>
> >
>
> >Julien,
>
> >
>
> >The units attribute cannot have "UTC" in it. UTC is implied. Other than
>
> >that, it looks great!
>
> >
>
> >Jim
>
> *De :*Julien Demaria
> *Envoy? :* vendredi 24 avril 2015 18:14
> *? :* 'Manning, Evan M (398B)'; Chris Barker
> *Cc :* Jonathan Gregory; cf-metadata at cgd.ucar.edu
> *Objet :* RE: [CF-metadata] How to define time coordinate in GPS?
>
> Hi,
>
> Thanks a lot for all your accurate answers!
>
> With all these information, for the moment we think the best way to
> represent our time in CF is to convert the time stamp of the units
> attribute from GPS to UTC.
>
> We cannot change it for the GPS beginning 1980-01-06 so we must
> transform the 2000-01-01 from GPS to UTC to be more CF compliant.
>
> We also specify GPS in the long name and in a new non standard
> time_reference attribute :
>
> int64 time_stamp(rows) ;
>
> time_stamp:standard_name = "time" ;
>
> time_stamp:units = "microseconds since 2000-01-01 00:00:*13*UTC" ;
>
> time_stamp:long_name = "Elapsed time since 01 Jan 2000 0h GPS" ;
>
> time_stamp:time_reference = "GPS"
>
> I think with this solution a CF compliant software (which not support
> leap second) should interpret time ?correctly?.
>
> Let me know if I missed something.
>
> Thanks,
>
> Julien
>
> *De :*Manning, Evan M (398B) [mailto:Evan.M.Manning at jpl.nasa.gov]
> *Envoy? :* vendredi 24 avril 2015 14:30
> *? :* Chris Barker; Julien Demaria
> *Cc :* Jonathan Gregory; cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>
> *Objet :* RE: [CF-metadata] How to define time coordinate in GPS?
>
> It's probably overkill but for Suomi NPP CrIS and ATMS we are planning
> to provide
>
> timestamps for each obs in both TAI and UTC.
>
> TAI is the true time dimension, but UTC gives users a correct UTC if
> that's what they want and should minimize the temptation for them to
> do TAI to UTC conversions using tools which don't understand leap seconds.
>
> -- Evan
>
> ------------------------------------------------------------------------
>
> *From:*Chris Barker [chris.barker at noaa.gov]
> *Sent:* Thursday, April 23, 2015 4:48 PM
> *To:* Julien Demaria
> *Cc:* Jonathan Gregory; cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>
> *Subject:* Re: [CF-metadata] How to define time coordinate in GPS?
>
> On Thu, Apr 23, 2015 at 7:19 AM, Julien Demaria
> <Julien.Demaria at acri-st.fr <mailto:Julien.Demaria at acri-st.fr>> wrote:
>
> I?m also not an expert on this:
>
> ?GPS, Global Positioning System time, is the atomic time scale
> implemented by the atomic clocks in the GPS ground control stations
> and the GPS satellites themselves. GPS time was zero at 0h 6-Jan-1980
> and since it is not perturbed by leap seconds GPS is now ahead of UTC
> by 16 seconds.?
>
> It seems to me then, that the "right" way is to express this time as:
>
> time_unit since 1908-01-06T00:00:00Z
>
> since that is technically exactly correct.
>
> clients are likely to translate to year-month-day-hour-minute-second
> using UTC, but maybe not. And as others have pointed out, most libs
> don't do leap seconds anyway, so are using "GPS time" whether they
> specify it or not.
>
> I guess what I am saying is that this isn't really a "how to encode it
> in CF" question -- if you use that epoch, then it becomes entirely up
> to the client what time it wants to translate to.
>
> -Chris
>
> http://www.leapsecond.com/java/gpsclock.htm
>
> a more detailed explanation:
>
> https://confluence.qps.nl/display/KBE/UTC+to+GPS+Time+Correction
>
> Thanks in advance,
>
> Julien
>
> >Jonathan Gregory j.m.gregory at reading.ac.uk <http://reading.ac.uk>
>
> >Thu Apr 23 07:58:09 MDT 2015
>
> >
>
> >Dear Julien
>
> >
>
> >Could you explain what the difference is between GPS time and UTC (for
> a non-
>
> >expert such as me)?
>
> >
>
> >Thanks
>
> >
>
> >Jonathan
>
> *De :*Julien Demaria
> *Envoy? :* jeudi 23 avril 2015 14:51
> *? :* 'cf-metadata at cgd.ucar.edu <mailto:cf-metadata at cgd.ucar.edu>'
> *Objet :* How to define time coordinate in GPS?
>
> Hi,
>
> I need to define a time coordinate variable which use the GPS time
> referential instead of UTC, but I did not found how to specify this.
>
> For the moment my variable look like this :
>
> int64 time_stamp(rows) ;
>
> time_stamp:standard_name = "time" ;
>
> time_stamp:units = "microseconds since 2000-01-01 00:00:00" ;
>
> time_stamp:_FillValue = -1L ;
>
> Thanks in advance,
>
> Julien
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu <mailto: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 <mailto:Chris.Barker at noaa.gov>
>
--
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 <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900
/We will be updating our social media soon. Follow our current Facebook
(NOAA National Climatic Data Center
<https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA
National Oceanographic Data Center <https://www.facebook.com/noaa.nodc>)
and Twitter (_at_NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150501/f6149df0/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/20150501/f6149df0/attachment-0001.png>
Received on Fri May 01 2015 - 07:42:55 BST
