Markus Kuhn said:
> Writing "24:00" to terminate a time interval at exactly midnight is
> pretty common practice and is even sanctioned by ISO 8601.
> See for example the railway timetable on
>
> http://en.wikipedia.org/wiki/24-hour_clock
>
> where trains arrive at 24:00 but depart at 00:00.
Us
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 posit
From: Rob Seaman <[EMAIL PROTECTED]>
Subject: Re: [LEAPSECS] Ambiguous NTP timestamps near leap second
Date: Thu, 16 Feb 2006 16:30:37 -0700
> 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
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
From: Markus Kuhn <[EMAIL PROTECTED]>
Subject: Re: 24:00 versus 00:00
Date: Thu, 16 Feb 2006 19:53:22 +
> Steve Allen wrote on 2006-02-16 19:25 UTC:
> > > 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.
> >
> > Minor poin
Ed Davies scripsit:
> If only the 24:00 for end of day notation wasn't in the way
> we could look at positive leap seconds as just being the
> result of deeming certain days to be a second longer than
> most and just use 24:00:00. We wouldn't have to muck with
> the lengths of any of the hours or
Markus Kuhn wrote:
With the 24-h notation, it is a very useful and well-established
convention that 00:00 refers to midnight at the start of a date, while
24:00 refers to midnight at the end of a date. Thus, both "today 24:00"
and "tomorrow 00:00" are fully equivalent representations of the same
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 12:12 PM, Markus Kuhn wrote:
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, then this
Steve Allen wrote on 2006-02-16 19:25 UTC:
> > 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.
>
> Minor point, I think it has to read more like this
>
> between 23:59:60 of a UTC day that ends with a positive leap
>
> "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
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 seco
"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.
N
13 matches
Mail list logo