From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Time resolution in Emacs argument optional ones Date: Fri, 22 Apr 2022 14:26:16 -0700 Organization: UCLA Computer Science Department Message-ID: References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> <83tuapvcxs.fsf@gnu.org> <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu> <83fsm8tdzl.fsf@gnu.org> <9e4781b2-2ffa-b1ce-09b4-ead82cad9038@cs.ucla.edu> <83ilr3siku.fsf@gnu.org> <4e41671c-fae8-61c4-845c-4c7ba4317e88@cs.ucla.edu> <83fsm7sh2s.fsf@gnu.org> <83czhbsgc2.fsf@gnu.org> <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu> <83y1zzq6kd.fsf@gnu.org> <837d7hr8s3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6835"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: Eli Zaretskii , manikulin@gmail.com, Emacs developers To: Corwin Brust Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 22 23:27:25 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ni0oG-0001eB-Re for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 23:27:24 +0200 Original-Received: from localhost ([::1]:53164 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ni0oF-0006SK-1U for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 17:27:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni0nJ-0005OC-2R for emacs-devel@gnu.org; Fri, 22 Apr 2022 17:26:25 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46314) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni0nH-00050H-0t; Fri, 22 Apr 2022 17:26:24 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EB3FB16005E; Fri, 22 Apr 2022 14:26:17 -0700 (PDT) Original-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 nem5ZM4g79n5; Fri, 22 Apr 2022 14:26:16 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B3BF21600C2; Fri, 22 Apr 2022 14:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-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 4xWzKlKvZynB; Fri, 22 Apr 2022 14:26:16 -0700 (PDT) Original-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 8515216005E; Fri, 22 Apr 2022 14:26:16 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:288808 Archived-At: On 4/22/22 11:52, Corwin Brust wrote: > Since this seems to be in reply to Eli's question about use-cases, can > you elaborate on some of the specific use-cases where 1/64th of a > second is insufficient? When Emacs needs to deal with more than 64 spaced events per second, or with external time sources that deal with more than 64 such events per second, a resolution of 1/64 second is inadequate. In my previous message I gave the example of comparing the current time in 1/64-second resolution to file timestamps in (say) 100 ns resolution, where Emacs can compare timestamps incorrectly. Another example would be comparing internally-generated timestamps to Internet RFC 3339 or ISO 8601 timestamps retrieved from the outside world. LANs synchronized via NTP can routinely synchronize clocks to less than 10 ms, and processes running on a single node can synchronize even more closely. But if Emacs reports the current time to within only 1/64 s, its timestamps introduce more clock skew than its underlying platforms do, making it harder to build distributed apps with high-quality timestamps. Of course most apps don't need high-quality timestamps. However, I don't see why Emacs would insist on generating low-quality timestamps if higher-quality timestamps are readily available.