Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760928Ab3IDTVE (ORCPT ); Wed, 4 Sep 2013 15:21:04 -0400 Received: from mail-ie0-f177.google.com ([209.85.223.177]:60702 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759529Ab3IDTU7 (ORCPT ); Wed, 4 Sep 2013 15:20:59 -0400 MIME-Version: 1.0 In-Reply-To: References: <5226FAE1.5070201@fb.com> Date: Wed, 4 Sep 2013 12:20:58 -0700 X-Google-Sender-Auth: kRG2YIqdmXL3lmHgGzjR5SFiNzY Message-ID: Subject: Re: clock_gettime_ns From: John Stultz To: Andy Lutomirski Cc: 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: 786 Lines: 21 On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski wrote: > I think that most of the hangup was a lack of agreement on how the API > should work wrt leap seconds. I don't recall this objection. The interface uses existing clockids, so it probably should keep the existing leap-second behavior of those clockids. > I've always thought that the Right Way to represent a UTC time is > nanoseconds since some epoch, where every potential leap second > counts. Check out the CLOCK_TAI clockid merged in 3.10. thanks -john -- 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/