Re: Ambiguous NTP timestamps near leap second

2006-02-16 Thread Markus Kuhn
M. Warner Losh wrote on 2006-02-14 21:18 UTC: ntp time stampes are ambiguous at leap seconds (the leap indicator bits aren't part of the time stamp, exactly), which is a good reason to change them. However, the cost to change them could be quite high if done in an incompatible manner. No,

Re: Ambiguous NTP timestamps near leap second

2006-02-16 Thread Steve Allen
On Thu 2006-02-16T19:12:30 +, Markus Kuhn hath writ: No reply from an NTP server shall ever represent any point in time between 23:59:60 and 24:00:00 of a UTC day. If a client requests an NTP timestamp and the response would represent a point in time during an inserted leap second,

Re: Ambiguous NTP timestamps near leap second

2006-02-16 Thread Markus Kuhn
Rob Seaman wrote on 2006-02-16 20:28 UTC: In fact, to simplify coding, simply reject all requests received between 23:59:00 and 24:01:00. Unlikely this would have any more significant effect in practice. While there is a 24:00:00, there is certainly *no* 24:00:00.0001. That would be

Re: Ambiguous NTP timestamps near leap second

2006-02-16 Thread Rob Seaman
On Feb 16, 2006, at 2:06 PM, Markus Kuhn wrote: While there is a 24:00:00, there is certainly *no* 24:00:00.0001. That would be 00:00:00.0001 instead. Says who? Didn't we just burn a lot of calories discussing whether UTC was a real number or a continuous function? Time does

Re: Ambiguous NTP timestamps near leap second

2006-02-16 Thread Rob Seaman
On Feb 16, 2006, at 4:46 PM, Warner Losh wrote:UTC rules state that the time sequence should be23:59:59.7523:59:60.023:59:60.2523:59:60.5023:59:60.7500:00:00.:00:00.25Well, no.  ITU-R-TF.460-4 says nothing whatsoever about the representation of time using sexigesimal notation: "2.2 A