Jonathan,
Having already given in on putting all this information into calendar
definitions instead of adding something like a time_system attribute, I
think this is a good approach overall.
I don't see any problem with using GPS or TAI before their epochs, since
they are linear systems. There is no question about how to represent a
time that is 1e12 seconds (for example) before the GPS epoch. However,
this actually does not hold for UTC because of the leap seconds. There
is no consistent and agreed-upon way to determine how to represent 1e12
seconds before the UTC epoch. The actual reference of the UTC epoch is
unclear. It was first defined in 1960, then adjusted to it's current
form in 1972 (see below).
[Doing some more reading, I found that UTC is currently defined in terms
of TAI, with leap seconds added to keep it within 1 second of Universal
Time (UT1). UTC was adjusted by a fraction of a second on 1972-01-01 so
that 00:00:00.000 UTC was 00:00:10.000 TAI. Before that, UTC was defined
in terms of UT1 directly, with many sub-second adjustments to keep it
aligned with UT1. UT1 is defined in terms of measurements of the Earths
rotational orientation relative to a number of quasars, which act as a
"fixed" inertial reference frame.]
I think I may have found a good name for "generic" time while doing the
reading summarized above. Mean Solar Time (MST) is the name for
idealized solar time at longitude 0 degrees at the equator of an
effectively seasonless Earth. It has no leap seconds, and is tied to the
idealized solar day, however long that day might be. It has an
unfortunate acronym share with Mountain Standard Time for North
Americans, but nothing is perfect. I think MST is what most other
calendars can be assumed to use. It's also what people with older
historical data should probably use.
If the community is good with making a calendar for each case (GPS, TAI,
UTC and NLS or MST), I'm good with that too.
Now for the "encoding" you are talking about. No time variable should
ever contain leap second artifacts within its elapsed time values, no
matter what calendar is used. We don't do it for days with Gregorian vs
Julian calendars, and we shouldn't do it for finer grained times with
UTC vs GPS, etc time systems.
The only way I am remotely good with telling people it is OK to allow
leap second artifacts in the values in a time variable is if we define
yet another calendar - gregorian_posix. It would be defined as having an
epoch date of 1970-01-01 00:00:00.000 UTC and an unknown presence of
leap second artifacts in both the reference time and the elapsed time
values, and would include an explanation of how the lack of leap second
handling in POSIX system time handling functions coupled with imprecise
internal clocks in computers and the widespread use of the Network Time
Protocol makes precision time accounting problematic when using such
systems.
And again, we should keep in mind that for time resolutions of 1 minute
or less, it won't matter what time system you pick. They all agree to
within 35 seconds in the worst possible case.
We could also redefine gregorian as an alias for gregorian_posix as a
way of warning users not to be too trusting, but deprecating gregorian
is OK too.
Grace and peace,
Jim
On 5/28/15 3:50 AM, Jonathan Gregory wrote:
> 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 -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
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
/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>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150528/6cdd5d42/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150528/6cdd5d42/attachment-0001.png>
Received on Thu May 28 2015 - 11:06:11 BST
