On Fri, May 29, 2015 at 11:18 AM, Jim Biard <[email protected]> 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 <[email protected]> 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 <[email protected]> >> <[email protected]> ----- >> >> >> Date: Thu, 21 May 2015 14:36:46 -0400 >> From: Jim Biard <[email protected]> <[email protected]> >> To: Jonathan Gregory <[email protected]> <[email protected]> >> CC: CF Metadata List <[email protected]> <[email protected]> >> 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: [email protected] >> 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 @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 <[email protected] >> >> 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 >> [email protected]http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> ----- End forwarded message ----- >> _______________________________________________ >> CF-metadata mailing >> [email protected]http://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: [email protected] >> 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 @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and >> @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. * >> >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> 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 > > [email protected] > > > -- > [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: [email protected] > 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 @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and > @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. * > > _______________________________________________ > CF-metadata mailing list > [email protected] > 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 [email protected]
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
