[opendtv] Re: A full explanation of the PSIP time issue.
- From: "johnwillkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 23 May 2007 18:40:18 -0700
1. This is informative, not normative. You can do it this way, or you can
do it another way.
2. "UTC is the time source we use to set our clocks."
3. Nothing in here says to use GPS time values.
4. " GPS time is used to represent future times" says NOTHING ABOUT CURRENT
TIMES and is consistent with my first explanation.
The main text is normative and is of more weight than Annex D.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Shutt
Enviado el: Wednesday, May 23, 2007 3:11 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: A full explanation of the PSIP time issue.
ATSC A/65C, Annex D, pages 124-125:
http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf
7. GPS TIME
The System Time Table provides time of day information to receivers. In
PSIP, time of day is represented as the number of seconds that have elapsed
since the beginning of "GPS time," 00:00:00 UTC January 6th, 1980. GPS time
is referenced to the Master Clock at the US Naval Observatory and steered to
Coordinated Universal Time (UTC). UTC is the time source we use to set our
clocks.
UTC is occasionally adjusted by one-second increments to ensure that the
difference between a uniform time scale defined by atomic clocks does not
differ from the Earth's rotational time by more than 0.9 seconds. The timing
of occurrence of these "leap seconds" is determined by careful observations
of the Earth's rotation; each is announced months in advance. On the days it
is scheduled to occur, the leap second is inserted just following 12:59:59
PM UTC.
UTC can be directly computed from the count of GPS seconds since January 6,
1980, by subtracting from it the count of leap seconds that have occurred
since the beginning of GPS time. In the months just following January 1,
1999, this offset was 13 seconds.
In the A/65 protocol, times of future events (such as event start times in
the EIT) are specified the same as time of day, as the count of seconds
since January 6, 1980. Converting an event start time to UTC and local time
involves the same calculation as the conversion of system time to local
time. In both cases, the leap seconds count is subtracted from the count of
GPS seconds to derive UTC.
GPS time is used to represent future times because it allows the receiver to
compute the time interval to the future event without regard for the
possible leap second that may occur in the meantime. Also, if UTC were to be
used instead, it wouldn't be possible to specify an event time that occurred
right at the point in time where a leap second was added. UTC is
discontinuous at those points.
Around the time a leap second event occurs, program start times represented
in local time (UTC adjusted by local time zone and [as needed] daylight
savings time) may appear to be off by plus or minus one second. PSIP
generating equipment may use one of two methods to handle leap seconds.
In method A, PSIP generating equipment does not anticipate the future
occurrence of a leap second. In this case, prior to the leap second, program
start times will appear correct. An event starting at exactly 10 AM will be
computed as starting at 10:00:00. But just following the leap second, that
same event time will be computed as 9:59:59. The PSIP generating equipment
should re-compute the start times in all the EITs and introduce the leap
second correction. Once that happens, and receivers have updated their EIT
data, the computed time will again show as 10:00:00. In this way the
disruption can be limited to a matter of seconds.
In method B, PSIP generating equipment does anticipate the occurrence of a
leap second, and adjusts program start times for events happening after the
new leap second is added. If the leap second event is to occur at midnight
tonight, an event starting at 10 AM tomorrow will be computed by receiving
equipment as starting at 10:00:01.
For certain types of events, the precision of method B is necessary. By
specifying events using a time system that involves no discontinuities,
difficulties involving leap seconds are avoided. Events such as program
start times do not require that level of precision. Therefore, method A
works well.
Consider the following example. Times are given relative to UTC, and would
be corrected to local time zone and daylight savings time as necessary.
* Time of day (UTC): 1:00 p.m., December 30, 1998
* Event start time (UTC): 2:00 p.m., January 2, 1999
* A leap second event will occur just after 12:59:59 p.m. on December 31
, 1998
* Leap seconds count on December 30 is 12
The data in the System Time message is:
* GPS seconds = 599,058,012 = 0x23B4E65C
* GPS to UTC offset = 12
Using method A (upcoming leap second event is not accounted for):
* Event start time in EIT: 599,320,812 = 0x23B8E8EC
* Converted to UTC: 2:00:00 p.m., January 2, 1999
* Number of seconds to event: 262,800 = 73 hours, 0 minutes, 0 seconds
Using method B (upcoming leap second event is anticipated):
* Event start time in EIT: 599,320,813 = 0x23B8E8ED
* Converted to UTC: 2:00:01 p.m., January 2, 1999
* Number of seconds to event: 262,801 = 73 hours, 0 minutes, 1 second
Note that using method B, the number of seconds to event is correct, and
does not need to be recomputed when the leap seconds count moves from 12 to
13 at year-end.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
