From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9AF383858C54 for ; Wed, 8 Mar 2023 08:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AF383858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678265994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RDA/o3Dea0L6gNWiGZcbEDNlKca4XVndZ8L14mS9LnU=; b=SmbdemnKtvvjbcExkR48hN8cEypqwS4Fbu2xmSl8Gn7/TJSKGh8rWJedbQz/TDmdiQT6sO kh7K0qEm+w6Vp6tjt2GCj5oZqbdyVdRjNWShpUXhQS1PgTX/SSGCN32hQI7EXLnf5GfKjz tLX7bjo1jeO7Rz7LFzpcRf5gPauAFlI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-177-VfRkB0ljP5i3y5-oXEsnvw-1; Wed, 08 Mar 2023 03:59:51 -0500 X-MC-Unique: VfRkB0ljP5i3y5-oXEsnvw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B2DD380280D; Wed, 8 Mar 2023 08:59:50 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.65]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A5BA31121314; Wed, 8 Mar 2023 08:59:49 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: Adhemerval Zanella Netto , libc-alpha@sourceware.org, Bruno Haible Subject: Re: [PATCH] time: Use CLOCK_REALTIME for time (BZ #30200) References: <20230306160321.2942372-1-adhemerval.zanella@linaro.org> <87ttywq0je.fsf@oldenburg.str.redhat.com> <32a9fa9c-2714-9e18-a3e7-bcfc2d61cd87@linaro.org> <87bkl4pyoa.fsf@oldenburg.str.redhat.com> <738d9792-1369-fe02-b4bf-0a3e0207413c@linaro.org> <877cvspxxa.fsf@oldenburg.str.redhat.com> Date: Wed, 08 Mar 2023 09:59:47 +0100 In-Reply-To: (Paul Eggert's message of "Tue, 7 Mar 2023 21:51:00 -0800") Message-ID: <874jqvty7w.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Paul Eggert: > On 2023-03-07 04:07, Florian Weimer via Libc-alpha wrote: >> Probably RESOLVED/MOVED because we get whatever time the kernel >> provides. It seems a deliberate kernel decision to me. > > For my own information, is 'time' the only standard function that uses > a clock other than CLOCK_REALTIME and so can be out-of-sync with > timespec_get? What about gettimeofday, futimens with UTIME_NOW, or > timestamps set by modifying files? Even if the same underlying clock is used, rounding may cause interface which use different precision for the fractional seconds part to report different integral seconds. The standard does not require rounding towards minus infinity. Thanks, Florian