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