[opendtv] Re: The Challenge
- From: "John Shutt" <shuttj@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 24 May 2007 16:53:03 -0400
John,
I am sorry to say that I believe there is at least one error of fact in your
"Lesson" as stated under "another help." I leave it to others to point it
out if they choose to do so. Or if they can show why I am incorrect in
thinking it is an error, then I apologize to you in advance.
However, that aside, let me make an admittedly amateurish stab at your
questions.
First question: "Step 1: Using just the GPS time value in the table above,
create the system time bytes for a system time table."
John hints that this task is impssible, but I disagree. Using A/65C, page
24 as a guide, which says:
"system_time - A 32-bit unsigned integer quantity representing the current
system time as the number of GPS seconds since 00:00:00 UTC, January 6th,
1980."
All one has to do in order to determine the value for <system_time> at any
given UTC time and date, is to determine how many GPS seconds have elapsed
between 6 January 1980 00:00:00 UTC and the current time.
When given the date 3 January 2003 00:03:02 GPS as the "current" time, one
has to determine the number of GPS seconds that have elapsed between 6
January 1980 00:00:00 UTC and that date.
I thought this challenge would be impossible for me to perform, but then I
found on the web a handy converter (see references below) that will take any
time and date, and create from it a Unix time stamp, or visa versa. Unix
time is much like the ATSC's <system_time> in that it is expressed as a
continuous count of seconds since a given "epoch" date. In the case of the
Unix time stamp, the epoch date is 1 January 1970, 00:00:00 and like the
ATSC's <system_time> value, it does not take into account any UTC leap
seconds. It is a continuous count of seconds that have elapsed since the
beginning of 1970. Therefore, using this tool one can convert any date to
Unix seconds without having to manually calculate the number of seconds in
any particular day, month, or factoring in leap years, etc., in order to
count the number of seconds that have passed since a date. I'm sure it's
cheating to use such a tool, and I apologize and forfeit my eligibility in
John's Challenge as a result, but let's go through the motions anyway.
However, this calculator and all of the others I found on the web all share
one problem, in that they do not take UTC leap seconds into account when
calculating a "human" time and date from a given Unix time stamp. Even
though the results are purported to be UTC by the program, it is really "GPS
time" referenced to UTC, i..e. the time and date displayed is in the UTC
"time zone" but no UTC leap seconds have been taken into account when
calculating the time and date. That is the definition of "GPS time" as used
by both me and John W, so it is not a problem but needs to be taken into
account when using the results of the program.
(A quick proof of this omission by the program can be done for the skeptic.
There was a leap second added to UTC on 12/31/2005 at 23:59:59. If this
calculator were taking leap seconds into account, the Unix Timestamp for the
date 1 January 2005 00:00:00 UTC should be three seconds more than the Unix
time stamp for 31 December 2005 23:59:58 UTC. Converting those times with
the program only shows a two second difference in the Unix time stamp values
of those two UTC times, therefore no additional second for the added UTC
leap second that occurred between those two times was made by the program.
Likewise, checking times for all of the other dates that UTC leap seconds
were added yielded similar results. Therefore, one can conclude, and in
fact the program states, that no UTC leap seconds were factored in by the
program, thus making any results "GPS time" for our purposes.)
So, to do the conversion:
1) - Translate 3 January 2003 00:03:02 GPS to the corresponding Unix time
stamp = 1041552182
2) - Subtract the Unix time stamp to GPS seconds offset factor. This can be
found by using the same program to determine the Unix time stamp for 6
January 1980 00:00:00, the GPS epoch when the GPS seconds count was exactly
zero. This offset = 315964800, so we subtract that from the Unix time stamp
to get the resulting GPS seconds = 725587382.
3) - Convert this base 10 number to base 16. <system_time> = 0x2B3F95B6.
John's second challenge:
"S(t)ep 2: Using just the UTC time value in the table above, create the
appropriate byte values to represent that time below."
I got lost at what John meant by "that time below", but again, using A/65C
as our guide, to convert the UTC time value given in John's Table 1 into a
<system_time> value, our first step is to translate 2 March 2009 01:45:20
UTC into GPS time. I am forced to assume that there will be no further leap
seconds added to UTC between the last one on 31 December 2005 (a link to the
full list of UTC leap seconds are in the references below), and the date
given. If there are, then my results will be off by those number of leap
seconds that my be added by the International Bureau of Weights and Measures
between now and that date.
1) - Since GPS time currently leads UTC time by 14 seconds, and we are
assuming that the same will hold true on 2 March 2009, we must add 14
seconds to UTC time to get GPS time. Therefore, GPS time = 2 March 2009
01:45:34
2) - As in the step above, we plug in that date and time into the Unix time
stamp generator, and get Unix time = 1235958334
3) - Subtract the Unix to GPS seconds conversion factor. GPS seconds =
919993534
4) - Convert decimal to hex. <system_time> = 0x36D5FCBE
John's third challenge:
"Step 3: Using just the system_time value in the table above, create the
appropriate byte values to represent that time span value in the table
below"
Again, John lost me with his wording, but I shall labor under the assumption
that John wanted the <system_time> byte 0xEF2906D2, as given in his Table 1,
translated into GPS time and UTC time.
1) - Convert the hex value into a decimal value. 0xEF2906D2 = 4012443346
This number represents the number of GPS seconds that have elapsed since
00:00:00 6 January 1980 UTC.
2) - Convert the GPS seconds value into a Unix time stamp value. To do so
we add the Unix-GPS offset factor of 315964800 to the GPS seconds value.
Unix time stamp = 4328408146.
3) - Cheat by plugging that time stamp into the Unix converter program to
arrive at the GPS time and date. GPS time = 1 March 2107 07:35:46. Wow,
John, I won't even try to convert that to UTC because I have no idea how
many leap seconds will occur between now and 2107. Will it suffice to say
that if no further leap seconds are added to UTC in the next 100 years, the
time will be 1 March 2107 07:35:32?
I admit my ignorance in that I could not follow what John wanted for Step 4,
so I humbly admit defeat. As for Steps 5 and 6, I already played that game
and lost in John's eyes, so since nobody can ever prove 5 and/or 6 to John's
satisfaction, his money was never in jeopardy.
Now for a challenge of my own to John W. Given the time of December 30,
1998 13:00:00 UTC, what is the corresponding <system_time> value in hex?
Using my method above, I get:
1) - Convert UTC time to GPS time. On December 30, 1998, the GPS-UTC offset
was 12. Therefore, the GPS date is 30 December 1998 13:00:12 GPS.
2) - Plug that date into the Unix time stamp calculator. Unix time stamp =
915022812
3) - Convert Unix time stamp to GPS time stamp by subtracting the offset
value. GPS seconds = 599058012
4) - Convert the decimal value to hex. <system_time> = 0x23B4E65C
What do you get, John? No need to show work, just the hex result.
I am expecting that I shall never receive a direct answer from you, John,
but if you do get a different result, I really would like to know. The
results of my example above are independently verifiable by a third party.
John
References:
ATSC Standard A/65, Revision C, with Amendment No. 1:
http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf
Unix time stamp calculator: http://www.epochconverter.com/ ,
http://www.onlineconversion.com/unix_time.htm , and others. (Those are the
two I used to cross check myself, but knowing the web, both could be based
on the same Java code, so if there are any errors in the code, it could be
in both programs.)
Explanation of UTC leap seconds and a list of dates observed since the
inception of UTC leap seconds in 1972:
http://tf.nist.gov:80/pubs/bulletin/leapsecond.htm
A Javascript page that shows the continuous current GPS time, UTC time, and
others, based on your PC's current time. It serves no real purpose here
other than to show which time, GPS or UTC, leads the other, and therfore
which way to subtract or add the leap year offset value <GPS_UTC_offset>
when converting from one form to the other.
http://www.leapsecond.com/java/gpsclock.htm
----------------------------------------------------------------------
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:
