Maarten,
Your use case is a good example of the sorts of things that start to
crop up when we get into applications where leap seconds matter. Thanks
for sharing it.
At the end of your email you mentioned the idea of time without leap
seconds as being based on TAI instead of UTC. I think this is one of the
points where confusion starts to creep in. TAI is like a fine-grained
equivalent of Julian Day Number. It is, at core, a continuous count,
with no concern for minute, hour, day, month, or year boundaries. You
can express it in cyclical calender & clock form as YYYY-MM-DD
HH:MM:SS.sss (for example) for convenience, but that doesn't impose
anything upon TAI. GPS time is like TAI. The natural expression of GPS
time is a number of weeks and seconds in the week since the GPS epoch
date & time.
UTC is at core a clock system, and is more akin to a calendar, such as
the Gregorian or Julian calendar, which breaks time up into cycles which
are related to the motion of the Earth. The cycles for the calendars are
days, months, and years. The cycles for UTC are seconds, minutes, hours,
and days. The cycles are an integral part of UTC, and leap seconds are
modifications to those cycles to keep midnight at longitude 0 degrees
occurring at 00:00:00 +- 0.9 seconds. This is fully analogous to leap
days being added to keep calendar cycles of years, months, and days
synchronized with the Spring Equinox.
The addition of leap seconds into UTC doesn't change the number of
seconds that have elapsed since some epoch any more than the addition of
leap days into a calendar changes the number of days that have elapsed
since an epoch. UTC is based on TAI in that it is synchronized on the
length of a second and the timing of when a new second begins.
I think that mashing these different kinds of time systems together when
thinking about them is part of what makes this topic even more confusing.
Grace and peace,
Jim
On 4/28/15 1:37 PM, Maarten Sneep wrote:
On 28-04-15 18:52, Jonathan Gregory wrote:
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
This is an interesting topic. When dealing with a low-earth orbit and
a satellite that moves at 7 km/s, you need to be careful with
coordinates, both in space & time, ignoring leap seconds will ensure
our geolocation is off by 10 times the requirements for each second we
miss.
Fortunately I deal with the data only at level 2, the coordinate
transforms (TAI, UT0, UT1 and UTC for time, many more for solar system
references) are part of Level 1B. There all leap seconds are dealt
with. (The topic is very interesting, surprisingly complex, especially
when using geoid calculations, and I'm glad someone else figured it
all out).
For Sentinel 5 precursor we use a moving epoch, which allows us to
ignore leap seconds, at least: mostly.
We have defined that the epoch we use is UTC midnight before the start
of the orbit, with the start of the orbit at spacecraft midnight. We
count milliseconds in each day. Leapseconds are absorbed into the
epoch, as they occur (by definition) only at the end of a day. The
only case where we will be 'wrong' for users that do not take
leapseconds into account, is for part of an orbit that started before
UTC midnight and ends after it, on a day that adds a leapsecond. This
will at most affect 50 minutes of observations for eac hadded leap
second during the mission. Since we provide the geolocation, this may
appear to the careful observer as an inconsistency. However, if you
are that careful, you will include leap seconds yourself. In our
processing this single second will not matter. Because we only observe
on the sun-lit part of the orbit, the dark side will absorb the leap
seconds, there is no continuous datastream that will cause trouble
later on (pun fully intended).
Of course, for this to work, the epoch definition in the time
coordinate must be UTC and include leap seconds, i.e. "milliseconds
since 2016-10-24 00:00:00" should really refer to that moment in UTC,
leap seconds and all (fully ISO-8601). If you really mean time without
leap seconds, then you are talking about TAI as a baseline, not UTC,
but also do you at that moment start to talk about a time coordinate,
not a calendar).
The daily offset then allows users to work out when the observation
was taken with the detail they require.
Oh, funny reference for the discussion: http://xkcd.com/1514/
Best,
Maarten Sneep
--
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
