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
--
KNMI
T: 030 2206747
E: maarten.sneep at knmi.nl
R: A2.14
Received on Tue Apr 28 2015 - 11:37:22 BST
