NTP_EPOCH_OFFSET off one hour

[Martin Runge-2]

Hi everybody on the list,

I think the NTP_EPOCH_OFFSET in private.h has 3600 seconds too much. 3600 s ==
1 hour, so it looks like a timezone problem, but it isn't.

I verified it in two ways:

1)
from the leap seconds file from http://www.cis.udel.edu/~mills/leap.html 
2272060800      10      # 1 Jan 1972
says Jan, 1st 1972 had 2272060800 seconds passed since 1.1.1900 00:00:00h

1972 was a leap year, so 1970 and 1971 both had 365 days and therefore

2* 365 * 24 *3600 seconds = 6307200 seconds

2208992400 + 6307200 = 2272064400
that is 3600 s (==1 hour) more than in the leap seconds file.

2)
boost_date_time:
long h = now.tv_sec / 3600;
long s = now.tv_sec % 3600;
long m = s / 60;
s = s % 60;
unsigned us = now.tv_usec;
   
boost::posix_time::time_duration td(hours(h)
                                                             + minutes(m)
                                                             + seconds(s)
                                                             + microsec(us));
 
boost::posix_time::ptime boost_time;
boost_time = ptime(boost::gregorian::date(1970, Jan, 1), td);

cerr << "Boost Time: " << boost_time << endl;

=> shows exactly the result I would expect from the NTP offset in the leap
seconds file.

best regards
Martin

_______________________________________________
Ccrtp-devel mailing list
Ccrtp-devel@...
http://lists.gnu.org/mailman/listinfo/ccrtp-devel

[Mattias Seeman]

Hi, all!

As Martin pointed out, NTP_EPOCH_OFFSET (in CVS) is probably off by one
hour. This is probably not a problem until someone uses ccRTP on one end
and some other library/application on the other end and cares about the
RTP/NTP timestamp correspondence.

As Martin mentions, Boost agrees with him; the output of this test
program excerpt follows:

@@
const uint32 NTP_EPOCH_OFFSET = static_cast<uint32>(2208992400ul);

using namespace boost::posix_time;
using namespace boost::gregorian;
time_period ntp_epoch_offset( ptime( date(1900, Jan, 1), seconds(0) ),
ptime( date(1970, Jan, 1), seconds(0) ) );
BOOST_CHECK_EQUAL( boost::uint32_t(
ntp_epoch_offset.length().total_seconds() ), NTP_EPOCH_OFFSET );
@@
+++

test_rtp_session.cpp(61): error in "rtp_ntp": check boost::uint32_t(
ntp_epoch_offset.length().total_seconds() ) == NTP_EPOCH_OFFSET failed
[2208988800 != 2208992400]

+++

Other RTP libraries agree too (from
http://www.openmash.org/lxr/source/rtp/ntp-time.h):

@@
/*
 * Number of seconds between 1-Jan-1900 and 1-Jan-1970
 */
#define GETTIMEOFDAY_TO_NTP_OFFSET 2208988800UL
@@


With the highest regard,
\Mattias Seeman


Martin Runge wrote:

> Hi everybody on the list,
>
> I think the NTP_EPOCH_OFFSET in private.h has 3600 seconds too much. 3600 s ==
> 1 hour, so it looks like a timezone problem, but it isn't.
>
> I verified it in two ways:
>
> 1)
> from the leap seconds file from http://www.cis.udel.edu/~mills/leap.html 
> 2272060800      10      # 1 Jan 1972
> says Jan, 1st 1972 had 2272060800 seconds passed since 1.1.1900 00:00:00h
>
> 1972 was a leap year, so 1970 and 1971 both had 365 days and therefore
>
> 2* 365 * 24 *3600 seconds = 6307200 seconds
>
> 2208992400 + 6307200 = 2272064400
> that is 3600 s (==1 hour) more than in the leap seconds file.
>
> 2)
> boost_date_time:
> long h = now.tv_sec / 3600;
> long s = now.tv_sec % 3600;
> long m = s / 60;
> s = s % 60;
> unsigned us = now.tv_usec;
>    
> boost::posix_time::time_duration td(hours(h)
>                                                              + minutes(m)
>                                                              + seconds(s)
>                                                              + microsec(us));
>  
> boost::posix_time::ptime boost_time;
> boost_time = ptime(boost::gregorian::date(1970, Jan, 1), td);
>
> cerr << "Boost Time: " << boost_time << endl;
>
> => shows exactly the result I would expect from the NTP offset in the leap
> seconds file.
>
> best regards
> Martin
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ccrtp-devel mailing list
> Ccrtp-devel@...
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel
>  

_______________________________________________
Ccrtp-devel mailing list
Ccrtp-devel@...
http://lists.gnu.org/mailman/listinfo/ccrtp-devel