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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
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 (_at_NOAANCDC <https://twitter.com/NOAANCDC> and @NOAAOceanData
<https://twitter.com/NOAAOceanData>) accounts for the latest information./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150428/61bda1b4/attachment-0001.html>
-------------- 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/20150428/61bda1b4/attachment-0001.png>
Received on Tue Apr 28 2015 - 13:14:19 BST
