Jonathan,
The point I'm trying to make about gregorian_nls is that it lacks any
mechanism for specifying which time system is being used for the timestamp
in the reference date & time. In Chris Little's terms (at least roughly),
gregorian_nls is incomplete because the timestamp in the reference date &
time lacks an associated epoch/origin. It is a calendar without an
associated CRS.
Take my example times in TAI, GPS and UTC from my previous email. Let's say
I wanted to set my reference date & time to that instant in history, and I
have a GPS timestamp. If I specified my calendar as gregorian_nls so I
could use my GPS timestamp, there is no way for a user of my file to know
that my timestamp was a GPS timestamp. They might assume it was a TAI
timestamp, and will then be 19 seconds off for every "absolute" time they
extract from the time variable elapsed time values.
For a complete representation, in Chris Little's terms, there must be a
CRS, a calendar, and a notation. gregorian_nls lacks a CRS. That's why I
suggested that we must either make a calendar for each different time
system, and add more as more people want to use more time systems, or we
state that the timestamp in the reference must be UTC. Declaring the
reference timestamp unambiguously as UTC doesn't force anyone to extract
absolute times from the time variable in UTC. It does require data
consumers to convert the UTC timestamp to GPS or TAI or whatever before
proceeding to extract absolute times from the time variable.
I'm OK with deprecating 'vanilla' gregorian, but there are so many cases
where it is sufficient even though it is incomplete that it seems a bit
draconian.
Grace and peace,
Jim
[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
<
http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<
http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
Twitter at _at_NOAANCEIclimate
<
http://www.twitter.com/NOAANCEIclimate>and _at_NOAANCEIocngeo
<
http://www.twitter.com/NOAANCEIocngeo>.*
On Thu, May 21, 2015 at 1:11 PM, Jonathan Gregory <j.m.gregory at reading.ac.uk
> wrote:
> Dear Jim
>
> I don't understand why you think gregorian_nls is not sufficiently
> specific.
> I think it indicates specifically that the conversion between timestamp and
> elapsed seconds is done without using leap seconds.
>
> > As an example, the date and time stamps as I'm writing this in the
> > different systems are:
> >
> > * TAI 2015-05-20 20:21:00
> > * GPS 2015-05-20 20:21:16
> > * UTC 2015-05-20 20:21:35
>
> If you have a timestamp of 2015-05-20 20:21:35 and you encode it with
> calendar="gregorian_utc" and units="seconds since 1980-01-06 00:00:00"
> you will get the same number (of seconds) as if you encode the timestamp
> of 2015-05-20 20:21:16 with calendar="gregorian_nls" and the same units.
> Have I got that right? Thus, this would be a way to encode GPS time (the
> original question). The same gregorian_nls calendar can be used to encode
> TAI time with units="seconds since 1958-01-01 00:00:00". The same software
> could do both - it needs to know the Gregorian calendar, and assumes that
> all days have 86400 s.
>
> > Redefine 'gregorian' to remove reference to UTC as Jonathan has
> > described, and state that presence or absence of leap second
> > artifacts in the reference timestamp and elapsed time values is not
> > known for a time variable that names this calendar. This is backward
> > compatible.
>
> I don't see an advantage in encouraging data-producers to be vague.
> Deprecating
> this calendar, so it gives a warning, might persuade them to specify what
> they
> are doing to encode their times.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150521/6efe99e7/attachment.html>
Received on Thu May 21 2015 - 12:36:46 BST
