From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 323C33858296 for ; Wed, 8 Mar 2023 23:08:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 323C33858296 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1385F160037; Wed, 8 Mar 2023 15:08:50 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id W4zEHehlNwjf; Wed, 8 Mar 2023 15:08:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3E1EE160066; Wed, 8 Mar 2023 15:08:49 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 3E1EE160066 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1678316929; bh=wo8RbFMTw77CFbNzCjr8kb4S8Ivhx68XW1kEpNl+Z4o=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=hZEZVjEfaKxAhOQV6VugroRVdg+/iRdlDvVFHI+j2GKsOa0CvPKqKMl4cQuzWwoTf AqqqbUvDL/Y14u/P2684qjF0nKLpoQtehds0Lxz349H8NpBa5ASK2A1aUVt+Rd5JSW 20eUoGtSZZs5TMItHZxIEKUQtm8AZw+8vDbjEFh8= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f6RbhO4Ct9Ur; Wed, 8 Mar 2023 15:08:49 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 1FEE2160037; Wed, 8 Mar 2023 15:08:49 -0800 (PST) Message-ID: <7f7c23db-15ce-c0bf-67b8-a11fab836c1a@cs.ucla.edu> Date: Wed, 8 Mar 2023 15:08:48 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] time: Use CLOCK_REALTIME for time (BZ #30200) Content-Language: en-US To: Florian Weimer Cc: Adhemerval Zanella Netto , libc-alpha@sourceware.org, Bruno Haible 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> <874jqvty7w.fsf@oldenburg.str.redhat.com> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <874jqvty7w.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/8/23 00:59, Florian Weimer wrote: > 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. Actually, POSIX does require rounding timestamps towards minus infinity for file timestamps, in its spec for utimensat. This requirement was put in because some implementations played fast and loose with these timestamps, with some rounding up and some rounding down, and this confusion caused more trouble than it was worth. Perhaps it would help if POSIX had a similar requirement for the 'time' function, as my impression from this discussion is that the confusion with 'time' being out-of-sync with CLOCK_REALTIME is also more trouble than it's worth. Anyway, thanks for clarifying what Glibc does.