Subject: [MMUSIC] RFC 4566bis - issue 7 - clarification

From: Colin Perkins <[email-masked]>
Date: Mon, 14 Jul 2008 23:56:42 +0100

On 10 Nov 2006, at 00:10, Alfred HÎnes wrote:
> (7)  clarification
>
> The second paragraph of Section 5.9, on page 17, says:
>
>    The first and second sub-fields give the start and stop times,
>    respectively, for the session.  These values are the decimal
>    representation of Network Time Protocol (NTP) time values in  
> seconds
>    since 1900 [13].  To convert these values to UNIX time, subtract
>    decimal 2208988800.
>
> To make the time base unique and absolute, the time zone (UTC)  
> needs to
> be specified.
> Hence, the RFC should say:
>
>    The first and second sub-fields give the start and stop times,
>    respectively, for the session.  These values are the decimal
>    representation of Network Time Protocol (NTP) time values in  
> seconds
> |  since 1900, UTC [13].  To convert these values to UNIX time,  
> subtract
>    decimal 2208988800.

Does anyone understand appendix E of RFC 1305 well enough to comment?  
I'm not sure this change is correct, but equally it's not clear that  
the current text is right either.

http://ftp.arnes.si/standards/rfc/rfc1305.pdf starting on page 70  
(you need the PDF version of this RFC...)

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jul 2008 14:28:55 +0200

Colin Perkins skrev:
>>    representation of Network Time Protocol (NTP) time values in seconds
>> To make the time base unique and absolute, the time zone (UTC) needs to
>> be specified.
>>    representation of Network Time Protocol (NTP) time values in seconds
>> |  since 1900, UTC [13].  To convert these values to UNIX time, subtract
>>    decimal 2208988800.
> 
> I'm not sure this change is correct, but equally it's not clear that the 
> current text is right either.
> 
> http://ftp.arnes.si/standards/rfc/rfc1305.pdf starting on page 70 (you 
> need the PDF version of this RFC...)
> 

In reality this likely hasn't been a problem as both NTP and Unix time 
uses UTC as base, but to be clear adding that is probably fine.

What I really wonder is how correct the "To convert these ..." is due to 
the leap seconds. To my understanding Unix times uses a definition that 
a day always is 86400 seconds. While to my understanding the NTP 
timestamp will contain the leap seconds. And if NTP timestamps are to be 
converted into UTC time year, day, hour and second then they need to be 
taken into account. Thus a simple subtraction will be giving the wrong 
time.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Jul 2008 15:13:57 +0200

On Jul 15 2008, at 14:28, Magnus Westerlund wrote:

>> Does anyone understand appendix E of RFC 1305 well enough to  
>> comment? I'm not sure this change is correct, but equally it's not  
>> clear that the current text is right either.
> In reality this likely hasn't been a problem as both NTP and Unix  
> time uses UTC as base, but to be clear adding that is probably fine.
>
> What I really wonder is how correct the "To convert these ..." is  
> due to the leap seconds. To my understanding Unix times uses a  
> definition that a day always is 86400 seconds. While to my  
> understanding the NTP timestamp will contain the leap seconds. And  
> if NTP timestamps are to be converted into UTC time year, day, hour  
> and second then they need to be taken into account. Thus a simple  
> subtraction will be giving the wrong time.

You might be able to solve the problem by not trying to (re-)define  
the NTP time scale, so I think this change goes exactly in the wrong  
direction.  The information about 1900 could go into a note instead,  
as well as the helpful sentence about subtracting 2208988800 to get a  
time scale that most engineers think they understand. Both should stay  
there, as they are pretty much true, and could be supplemented by  
mentioning UTC somewhere.  In the note.
(The 2208988800 may not be exactly true to fractional values,  
depending on your definition of "UNIX time", which might mean the  
strange beast "POSIX.1 system time" and then suddenly become way more  
complex in the vicinity of leap seconds, but nobody will care in the  
context of this standard.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Jul 2008 15:13:57 +0200

Gruesse, Carsten