On Fri, May 29, 2015 at 11:18 AM, Jim Biard <jbiard at cicsnc.org> wrote:
> 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.
>
+1
-Chris
> 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> 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> <jbiard at cicsnc.org> -----
>>
>>
>> Date: Thu, 21 May 2015 14:36:46 -0400
>> From: Jim Biard <jbiard at cicsnc.org> <jbiard at cicsnc.org>
>> To: Jonathan Gregory <j.m.gregory at reading.ac.uk> <j.m.gregory at reading.ac.uk>
>> CC: CF Metadata List <cf-metadata at cgd.ucar.edu> <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
>> o: +1 828 271 4900
>>
>> *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 @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
>>
>> 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 listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> CF-metadata mailing listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>> --
>> [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 <%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
>> 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
>
>
> --
> [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
> <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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150529/5f53f410/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/5f53f410/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/5f53f410/attachment-0003.png>
Received on Fri May 29 2015 - 21:31:51 BST
