Dear Jim, Jonathon, and old and new timers,
Here are my 2 cents worth:
http://www.bipm.org/en/bipm-services/timescales/ "The UTC scale is adjusted from
International Atomic Time (TAI) by the insertion of leap seconds"
http://en.wikipedia.org/wiki/Coordinated_Universal_Time "UTC is defined by
International Telecommunications Union Recommendation (ITU-R TF.460-6),
Standard-frequency and time-signal emissions and is based on International Atomic Time
(TAI) with leap seconds added at irregular intervals to compensate for the slowing of
Earth's rotation. .... Days are conventionally identified using the Gregorian calendar,
but Julian day numbers can also be used."
So, UTC is not a calendar, it is a timescale.
Consequently, I like and am trying to promulgate the terminology:
A 'timescale' is a repeating physical event that is counted. A 'clock' is a
device for doing so.
A 'temporal/time coordinate' is a mathematical generalisation of a timescale,
assuming continuity, interpolation, extrapolation and conventional arithmetic;
A 'calendar' is a set of algorithms, often not well defined, usually assuming
an underpinning coordinate reference system or timescale and relating it to
astronomical stuff (rotation of Earth, Mars, moon, sun, etc).
It then seems most sensible to recognise that ISO8601 is really a mixture of
the above, plus a standardised set of notations.
If any community use the notation of the current ISO8601 standard, I think that
the presumption must be that the Gregorian calendar, leap days and leap seconds
are implied, and thus they should indicate any deviations from this explicitly.
I am motivated by the increasingly wider use of our data in other domains, so
that explicit labelling becomes important.
HTH, Chris
Date: Tue, 28 Apr 2015 17:52:53 +0100
From: Jonathan Gregory <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear Jim
I agree that TAI and GPS aren't distinct CF calendars if they differ only
because of the epoch. In CF and udunits, the reference time is part of the the
units, as you know; it's not a property of the calendar. I referred to GPS
calendar just to contrast it with UTC.
Unlike you, I don't live only in the real world. :-) Many models use the
default CF calendar (called standard or gregorian) as an approximation to the
real world. In these models there are no leap seconds, and it would not be
correct to call this UTC, or to include the leap seconds in the encoding and
decoding of time cooordinates. In any case, as we understand, most software
doesn't allow for leap seconds. For those two reasons, I propose that we more
precisely define the default (standard, gregorian) calendar to say explicitly
that it does not include leap seconds i.e. every day is 86400 s long exactly.
This is probably correct for most of the data which has been written with this
calendar.
I call UTC a calendar because it affects the encoding, since it implies leap
seconds. You suggest, I think, that the treatment of leap seconds should be
indicated in the reference time in the units string. This doesn't seem quite
right to me because the units doesn't say anything about the encoding. We use
the same format of units string for all calendars. udunits does mention UTC in
respect of the format of this string because of wanting to talk about time
zones, not because of leap seconds. Time zones could be used in models too
(though I don't know of a case). Hence I still propose that we should regard
UTC as a calendar, if it's correct that the leap seconds in use in the real
world are part of the definition of UTC. This means we should define a a new
calendar, which is not the default, in which time units have just the same
format as usual i.e. udunits, but the encoding and decoding of values is done
including leap seconds according to UTC. The same value, with the same units
string, may translate into a different date-time (by a number of
seconds) according to whether the calendar is default (standard, gregorian) or
utc. It wouldn't make sense to use this calendar for dates before the
introduction of UTC, so it should be illegal to do so. We could do this by
prohibiting reference times earlier than the start of UTC and negative values
of time in this calendar.
Maybe I haven't grasped your point properly?
Best wishes
Jonathan
----- Forwarded message from Jim Biard <[email protected]
Date: Tue, 28 Apr 2015 11:35:16 -0400
From: Jim Biard <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
Gecko/20100101 Thunderbird/31.6.0
Jonathan,
I see where you are coming from, and there's validity in that line of thought.
Leap seconds represent a finer-grained adjustment to the overall date/time
system being used. I still think it makes good sense to add a new attribute to
declare whether or not leap second handling was used or strengthen our
standards for time variables so that problems are averted.
>From a human understandability perspective, a calendar attribute of
"GPS" or "UTC" will be somewhat confusing. In my experience, people don't speak of
the UTC calendar, it's UTC time. Further, TAI and GPS time don't really concern themselves with
anything but counts of seconds since an epoch date & time. People convert the counts to time stamps
for convenience, but they are actually more equivalent to the Julian Day Number (JDN) than they are to
the Gregorian or Julian calendar. TAI and GPS time have different epochs, and TAI is more accurate, but
they both are running counts of seconds that aren't tied to the motions of the Earth. As a result, I
think that it's improper to talk about a GPS calendar or TAI calendar.
What is being exposed by this discussion is the reality that any of us (myself
included) have often ignored or been unaware of the fact that the time
calculators (time handling software) we used when filling our time variables
with elapsed times weren't giving us true counts of seconds since the epochs we
wrote into our units attributes. If you are working at a resolution of days or
hours, this will probably never cause a problem. If you are working at a
resolution of minutes or less and working over a time span of greater than two
years, it may well have caused at least occasional small problems. If you are
working with full-resolution polar-orbiting satellite data, one second
represents ~7 km of satellite motion, so such errors can produce significant
geolocation errors.
A set of elapsed seconds since a Gregorian/UTC epoch that were calculated from
Gregorian/UTC time stamps without regard for leap seconds and which crossed a leap second
boundary are not "GPS"
seconds. Nor are they "UTC" seconds. They are, strictly speaking, elapsed times
into which one or more step errors have been introduced. As I mentioned in a previous
email, as long as you use the same time calculator to extract time stamps as you did to
get elapsed times from input time stamps, you won't notice anything. You may notice a
problem if you are taking differences between elapsed times and a leap second boundary
gets involved.
As I've considered all of this more, I'm tending to favor the second option I
suggested.
We could also be more strict, and say the epoch time stamp in the units
attribute must always be in UTC. The question would then be reduced to
whether or not leap seconds were counted into the elapsed times stored
in the time variable. In this case, we could add a "leap_seconds"
attribute which would have a value of "UTC" if UTC leap seconds were
counted into the elapsed times, and "none" if not. This would also allow
for some other system of leap seconds to be used. (I don't know if there
are others.) For backward compatibility, considering history, the
default value for this attribute would probably be "UTC".
Clearly, having epoch time stamps with time zone offsets from UTC, as described
in the CF conventions, would be OK as well. I'm also open to other namings for
the new attribute and for its possible values. The leap seconds only become an
issue in certain rather specific instances, so I think that such an attribute,
along with a bit of discussion in the document, would likely be sufficient to
warn those people that may find themselves negatively affected by improper leap
second handling.
Grace and peace,
Jim
On 4/27/15 1:07 PM, Jonathan Gregory wrote:
Dear Jim
I don't think calendars are the right place to encode this. We could
add a new "time_system" attribute where you would declare whether your
time stamps and elapsed times were based on UTC, GPS, TAI, etc.
If we take this route, we should require the elapsed times to encode
leap seconds if the time system is UTC, and state that the default
time system is UTC.
I think this is a calendar issue because the calendar is the set of
rules which translate between components of time (YMDhms) and elapsed
time (in fixed time units) since the reference time. Your later email
seems to me to be consistent with that. In the real world, the elapsed
interval (expressed e.g. as the number of seconds) between the ref
YMDhms and the actual YMDhs depends on whether your calendar includes leap
seconds (UTC) or not (GPS).
It seems that GPS is the calendar likely to have been assumed in
existing CF datasets, so it would be logical to say that the default is
the real- world calendar without leap seconds. Have I misunderstood
something? If we regard this as a property of the calendar, we don't need a new
attribute.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[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
/We will be updating our social media soon. Follow our current Facebook (NOAA
National Climatic Data Center
<https://www.facebook.com/NOAANationalClimaticDataCenter> and NOAA National
Oceanographic Data Center
<https://www.facebook.com/noaa.nodc>) and Twitter (@NOAANCDC
<https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
------------------------------
Subject: Digest Footer
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
------------------------------
End of CF-metadata Digest, Vol 144, Issue 15
********************************************
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
