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 BD2903858C30 for ; Wed, 8 Mar 2023 05:51:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD2903858C30 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 AAD75160041; Tue, 7 Mar 2023 21:51:01 -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 7wg-e5bYiJmz; Tue, 7 Mar 2023 21:51:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E95AC160044; Tue, 7 Mar 2023 21:51:00 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu E95AC160044 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1678254661; bh=YwJ46SgXicJUI73LUiUn+cxxOe+9b5H3C4WUpQd9hxc=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=O9RzCVhPmMGeoAKOgBZAqvS5qoP/T/jZMhGZP289SIugOmB8Ui7F7fDXG8n1lEboM wPIgYe/XrXEMRQZVOUhr8kng6deet4tUM3JzjIBefZ96TdHhuJFQexztViz5k9HWah GjfCVSAMcg8Aj69vuoKz58VAEBl5n2nPmMZ7+4y8= 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 aBOVmc3cwOpv; Tue, 7 Mar 2023 21:51:00 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B77D4160041; Tue, 7 Mar 2023 21:51:00 -0800 (PST) Message-ID: Date: Tue, 7 Mar 2023 21:51:00 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US To: Florian Weimer , Adhemerval Zanella Netto Cc: 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> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH] time: Use CLOCK_REALTIME for time (BZ #30200) In-Reply-To: <877cvspxxa.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 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 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? My idea is to go through the apps I help maintain, and make sure that they never call 'time' anywhere that it's important that a timestamp be in sync with with the rest of the system, since Glibc 'time' is out of sync in that way.