Chris,
I agree with you. So, going with the approach of defining new calendars,
how about this?
Define gregorian_mst (or gregorian_nls) as using Mean Solar Time as its
time system, and say that uncertainties of less than 0.5 minutes in the
time variable values are to be viewed with suspicion.
Grace and peace,
Jim
On 5/29/15 1:05 PM, Chris Barker wrote:
> On Thu, May 28, 2015 at 10:06 AM, Jim Biard <jbiard at cicsnc.org
> <mailto:jbiard at cicsnc.org>> wrote:
>
> 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.
>
>
> Exactly -- so the Calendar is ONLY for defining the reference
> timestamp in the units. Period. End of story. The actual values are
> seconds, or days, or .. and should always be clearly defined units in
> a nice continuous time.
>
> However, it seems from this discussion that there is concern that
> while the actual times SHOULD be "clean", the reality is that there
> maybe some "contaminated" data sets out there, and there should be
> some standard way to communicate this to the end-user of the data.
>
> If that's the case, then it shouldn't be the Calendar attribute.
>
> On the other hand, if you are a data provider, and you know that
> you're time axis is "messed up" -- you should probably fix it, rather
> than indicating that it's messed up.
>
> -Chris
>
>
>
>
>
> 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> <mailto:jbiard at cicsnc.org> -----
>>
>>> Date: Thu, 21 May 2015 14:36:46 -0400
>>> From: Jim Biard<jbiard at cicsnc.org> <mailto:jbiard at cicsnc.org>
>>> To: Jonathan Gregory<j.m.gregory at reading.ac.uk> <mailto:j.m.gregory at reading.ac.uk>
>>> CC: CF Metadata List<cf-metadata at cgd.ucar.edu> <mailto: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/> <http://www.cicsnc.org/>Visit us on
>>> Facebook<http://www.facebook.com/cicsnc> <http://www.facebook.com/cicsnc>*Jim Biard*
>>> *Research Scholar*
>>> Cooperative Institute for Climate and Satellites NC<http://cicsnc.org/> <http://cicsnc.org/>
>>> North Carolina State University<http://ncsu.edu/> <http://ncsu.edu/>
>>> NOAA National Centers for Environmental Information<http://ncdc.noaa.gov/> <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 <tel:%2B1%20828%20271%204900>
>>>
>>> *Connect with us on Facebook for climate
>>> <http://www.facebook.com/NOAANCEIclimate> <http://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
>>> <http://www.facebook.com/NOAANCEIoceangeo> <http://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
>>> Twitter at _at_NOAANCEIclimate
>>> <http://www.twitter.com/NOAANCEIclimate> <http://www.twitter.com/NOAANCEIclimate>and _at_NOAANCEIocngeo
>>> <http://www.twitter.com/NOAANCEIocngeo> <http://www.twitter.com/NOAANCEIocngeo>.*
>>>
>>>
>>> On Thu, May 21, 2015 at 1:11 PM, Jonathan Gregory <j.m.gregory at reading.ac.uk <mailto: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 <mailto: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 <mailto: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 <tel:%2B1%20828%20271%204900>
>
> /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>. /
>
>
>
> _______________________________________________
> 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
/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/20150529/fb8c3d52/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/20150529/fb8c3d52/attachment-0002.png>
-------------- 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/20150529/fb8c3d52/attachment-0003.png>
Received on Fri May 29 2015 - 12:18:13 BST
