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 request shall be ignored.
I don't really have a dog in this race. The proposed fix sounds quite reasonable. I merely want to point out that sexigesimal notation is more forgiving than some messages on this list might suggest. I believe I previously mentioned that the image processing software we distribute to the astronomical community interprets a sexigesimal number as a floating point representation of hours, e.g., 23:30:00 ~= 23.5 hours. (One could alternately argue for an interpretation as a fraction of a day, something like 12:00:00 ~= 0.5 days.) The point under this interpretation is that it is completely legal for each of the colon delimited fields to exceed 24 hours or 60 minutes or 60 seconds: = 123:544:99.2222 132.09422838889 and, of course: = 23:59:60 24. We also have a %h printf format that inverts the process and enforces more familiar rules: printf ("%h\n", 23:59:60) 24:00:00.0 printf ("%h\n", 123:544:99.2222) 132:05:39.2 (Normal floating point precision issues apply, of course.) Note also that the values are not expressed as string literals. This is not a unique usage. Used to have a Casio (?) calculator that could similarly process such values as fractions. And our microwave is surely not unique in permitting times to be entered as arbitrary numbers of minutes and arbitrary numbers of seconds. For this discussion, we really only have to exclude the range 23:59:60-24:00:00 (and only during leap second events). A value larger than 24:00:00 can be handled consistently by interpreting it as so many seconds into the next day. What we're really excluding is the range 86400-86401 seconds from the start of the day in question, no matter how that time interval is expressed. 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. Or, of course, better yet - why don't we try it and see if it works rather than speculating. Rob Seaman NOAO