Dear Jim
Thanks for your email. I see what you mean. The calendar attribute does not
indicate only which set of rules are used for encoding and decoding, but it
also indicates the time coordinate reference system in which the timestamps
are interpreted (both the reference timestep in the units and the decoded time
coordinates). I had not distinguished these in my mind because they go together
in all the cases CF currently distinguishes. The difference in this new debate
is that the GPS and TAI time reference system use the same set of rules
(Gregorian no-leap-second) but a given timestep doesn't refer to the same
instant in the real-world in the two systems, so you need to know which one it
is, as you have pointed out. Thanks for pursuing this.
Therefore here's my latest suggestion. We should have *four* calendars,
gregorian_gps, gregorian_tai (this hasn't been requested yet, so according to
our usual practice we could omit it for the moment since we haven't been given
a use-case), gregorian_utc and gregorian. The first two calendars use the
no-leap-second encoding. gregorian_gps is for the GPS time reference system and
is not allowed for timestamps earlier than 1980-1-6 or with ref times earlier
than that (the GPS epoch), and TAI correspondingly not before the TAI epoch
(1958-1-1 I think you said). If you are using either of those time systems, it
can't be meaningful to extend them before their epochs, can it? gregorian_utc
is for encoding UTC time with leap seconds. This calendar can be used for any
previous time before UTC began as well (with the Julian/Gregorian calendar
change as in udunits, except that we might exclude years before 1 - we can come
back to that).
The gregorian calendar encodes UTC time (and before) *without* leap seconds. I
anticipate you might not be happy with this, but I'm putting it forward because
I think we agree that this is what is often, or usually, done with real-world
time, since most software doesn't support leap seconds. In the description, we
must point out that this encoding is faulty, because when leap seconds are
inserted or removed the encoded time coordinate may have a missing or repeated
second. Therefore it shouldn't be used for purposes where precision to the
second is important, but clearly for most real-world purposes it's fine in
practice, because that's what's done and people don't report problems. I think
it is better to be explicit about the choice between gregorian_utc and
gregorian, rather than leave it vague which has been used.
If we think it's preferable we could also define gregorian_nls with the same
meaning and deprecate gregorian, so that a warning is generated by the checker,
in order to encourage data-writers to check if they're making the right choice.
I assume that all the other calendars are also no-leap-second ones since they
are for model data (including proleptic_gregorian) and this should be stated.
For reference, I repeat what else I proposed earlier, to make this complete:
* Don't mention "UTC" in the description of time units. Instead say the time
zone of the Greenwich meridian, without summmer/daylight-saving time.
* Clarify that in the CF convention the choice of "calendar" implies the
particular set of rules that is used to convert between date-times (YYYY-MM-DD
hh:mm:ss i.e. sets of six numbers) and time coordinates in units of elapsed
time since a reference time. The calendar is identified by the calendar att of
of the time coordinate variable. It's a property of the time coord variable.
... and now we also have to point out that calendar has an additional
implication of reference system for the real world
* Require the calendar to be specified i.e. no default, and abolish the
"standard" calendar (currently a synonym for the default). These are backward-
incompatible changes for data-writers, but of course they do not invalidate any
data written with old CF versions.
Best wishes and thanks
Jonathan
----- Forwarded message from Jim Biard <jbiard at cicsnc.org> -----
> Date: Thu, 21 May 2015 14:36:46 -0400
> From: Jim Biard <jbiard at cicsnc.org>
> To: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> CC: CF Metadata List <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] How to define time coordinate in GPS?
>
> 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
> >
----- End forwarded message -----
Received on Thu May 28 2015 - 01:50:44 BST
