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,
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,
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
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
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
