Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755202Ab3IIRrX (ORCPT ); Mon, 9 Sep 2013 13:47:23 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:48315 "EHLO mail-vc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950Ab3IIRrV (ORCPT ); Mon, 9 Sep 2013 13:47:21 -0400 MIME-Version: 1.0 In-Reply-To: References: <5226FAE1.5070201@fb.com> <52279E1D.3060907@linaro.org> <5227B432.8070205@zytor.com> From: Andy Lutomirski Date: Mon, 9 Sep 2013 10:47:01 -0700 Message-ID: Subject: Re: clock_gettime_ns To: "H. Peter Anvin" Cc: John Stultz , Arun Sharma , LKML , Kumar Sundararajan Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1091 Lines: 25 On Wed, Sep 4, 2013 at 6:22 PM, H. Peter Anvin wrote: > I think it would be crazy encoding UTC with a non-POSIX scheme. The whole point is to find a good way to return the time that solves the problems with the POSIX scheme. Some of the problems, as I see them, are: - Performance: seconds + nanoseconds is expensive to compute and expensive to use. - Leap seconds, part 1: Times like 23:59:60.1 are not representable. - Leap seconds, part 2: The limited leap-second support that already exists (via the NTP APIs) is so obscure that it's frequently broken. - Offsets between clocks can't be read without using complicated calls like adjtimex. I think that coming up with something that's both non-POSIX and half-arsed is a bad idea, but doing something that's non-POSIX and well thought-through could be valuable. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/