[Ntp] Antw: Re: Antw: [EXT] Timescales, leapseconds and smearing

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Wed, 09 December 2020 07:00 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06363A0B26 for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 23:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O-4GjKZ7dAD for <ntp@ietfa.amsl.com>; Tue, 8 Dec 2020 23:00:51 -0800 (PST)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3933A0FFA for <ntp@ietf.org>; Tue, 8 Dec 2020 23:00:09 -0800 (PST)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3DD1C6000051 for <ntp@ietf.org>; Wed, 9 Dec 2020 08:00:07 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 1C34B6000050 for <ntp@ietf.org>; Wed, 9 Dec 2020 08:00:07 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 09 Dec 2020 08:00:07 +0100
Message-Id: <5FD075F4020000A10003D67F@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.0
Date: Wed, 09 Dec 2020 08:00:04 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: kurt@roeckx.be
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <X86sVykHUqlkXP96@roeckx.be> <5FCF4DC8020000A10003D5FB@gwsmtp.uni-regensburg.de> <X89eBhhdUDijLVpL@roeckx.be>
In-Reply-To: <X89eBhhdUDijLVpL@roeckx.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/gaNeC9FKNwXgnnUbZKxSQco5ijc>
Subject: [Ntp] Antw: Re: Antw: [EXT] Timescales, leapseconds and smearing
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 07:00:53 -0000

>>> Kurt Roeckx <kurt@roeckx.be> schrieb am 08.12.2020 um 12:05 in Nachricht
<X89eBhhdUDijLVpL@roeckx.be>:
> On Tue, Dec 08, 2020 at 10:56:24AM +0100, Ulrich Windl wrote:
>> Hi!
>> 
>> I think if we agree to use anything other than UTC in NTPv5, we absolutely
>> need to specify some use-level API how to get the current time:
>> time()
>> gettimeofday()
>> clock_gettime()
>> localtime()
>> strftime()
>> 
>> They all assume UTC... It's rather useless if NTP has the exact time, but no
>> ("standard") program can use it.
> 
> They don't use UTC, they use POSIX/UNIX time. POSIX time, just like
> NTP, ignores the leap seconds. POSIX actually says that the length
> of a second is not specified, an implementation can then say it's
> SI seconds. POSIX has support for a leap second in struct tm, so as
> long as you don't convert it to a time_t you can work in UTC.

Hi!

Can you be more specific? I only see:

           struct tm {
               int tm_sec;    /* Seconds (0-60) */
               int tm_min;    /* Minutes (0-59) */
               int tm_hour;   /* Hours (0-23) */
               int tm_mday;   /* Day of the month (1-31) */
               int tm_mon;    /* Month (0-11) */
               int tm_year;   /* Year - 1900 */
               int tm_wday;   /* Day of the week (0-6, Sunday = 0) */
               int tm_yday;   /* Day in the year (0-365, 1 Jan = 0) */
               int tm_isdst;  /* Daylight saving time */
           };

The practical reason when POSIX does not specify the length of a second seems to allow clocks with errors; demending that  it's an SI second yould pose relly trouble on implementers I'm afraid.

Regards,
Ulrich

> strftime() works with a struct tm, so can work in UTC.
> 
> The linux kernel has support for TAI. You can set a TAI offset, so
> that applications making use of the POSIX API still get the POSIX
> time. The clock_gettime() function you mentioned has TAI support.

Again, can you be more specific. I only see:

       The  res  and  tp  arguments  are  timespec structures, as specified in
       <time.h>:

           struct timespec {
               time_t   tv_sec;        /* seconds */
               long     tv_nsec;       /* nanoseconds */
           };

And the letters TAI appear nowhere in the description.

> The information to convert from TAI to UTC is available, so it's
> possible to work in TAI or UTC on Linux, it's just that most
> applications don't.

And when not using Linux?

Regards,
Ulrich
[...]