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) @ 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; [email protected]
*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:[email protected]]
*Envoyé :* vendredi 24 avril 2015 14:30
*À :* Chris Barker; Julien Demaria
*Cc :* Jonathan Gregory; [email protected]
<mailto:[email protected]>
*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 [[email protected]]
*Sent:* Thursday, April 23, 2015 4:48 PM
*To:* Julien Demaria
*Cc:* Jonathan Gregory; [email protected]
<mailto:[email protected]>
*Subject:* Re: [CF-metadata] How to define time coordinate in GPS?
On Thu, Apr 23, 2015 at 7:19 AM, Julien Demaria
<[email protected] <mailto:[email protected]>> 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
*À :* '[email protected] <mailto:[email protected]>'
*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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
--
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: [email protected] <mailto:[email protected]>
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 (@NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
