From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Time resolution in Emacs Date: Sat, 23 Apr 2022 09:27:35 +0300 Message-ID: <83czh8pb54.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31091"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manikulin@gmail.com, corwin@bru.st, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 23 08:29:15 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 1ni9Gd-0007wX-0J for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Apr 2022 08:29:15 +0200 Original-Received: from localhost ([::1]:37478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ni9Gb-0001tu-KK for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Apr 2022 02:29:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni9F4-0001Cs-EQ for emacs-devel@gnu.org; Sat, 23 Apr 2022 02:27:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni9F3-0001gU-0L; Sat, 23 Apr 2022 02:27:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9Bq/hcS18Kegjp+iCPx3xRezGdj0OWOJdo5sjxClXBw=; b=SpLwM8tU0ah5 J19dZpCRS8kFz74V/DeNU/mFN8rWVV+soQ6Wmzrp6l7KXs2e40sJ/gaDefvoFdVa27yAdidFbn1Lm AyXlBCY0VF7skFbZDQhZA2noAzm8364jMJOHkiBjCLF2zwVNLIaLAZmjYdfRUoLTH05rbRp9vt9OR IGJS/dHnYhgyRb0HchETZDe12cxJxy5Xj91LII9zXnQGCjApTi631fqFWBDYWUOMZvQBA+ubMzokR qwkG6KYqF3VIKrpIOONQv/roL31ACSnazWrIoOB5YaaKN50GM/g9nQdQY1JI+ZdaQaofEKuQqYYqN TdeO/2FkO1BteRR3M3Jfbg==; Original-Received: from [87.69.77.57] (port=1294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni9F2-0004Cp-EQ; Sat, 23 Apr 2022 02:27:36 -0400 In-Reply-To: (message from Paul Eggert on Fri, 22 Apr 2022 14:26:16 -0700) 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:288812 Archived-At: > Date: Fri, 22 Apr 2022 14:26:16 -0700 > Cc: Eli Zaretskii , manikulin@gmail.com, > Emacs developers > From: Paul Eggert > > 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. You will excuse me, but I find these examples artificial when Emacs Lisp programs are concerned. There's no reason to expect Emacs to be able to support such applications on all platforms. Not to mention that synchronizing clocks to millisecond accuracy on non-RT systems is in most cases futile, because the OS doesn't provide reliable timings to that accuracy anyway. > 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. We don't _insist_ on providing low-accuracy timestamps, but we should definitely be certainly concerned about adding such non-trivial complexity to Emacs for the benefit of extremely rare (if any) use cases. So far I have yet to see an example of an important use case that would justify that, let alone a plan for reasonably practical ways of providing the time resolution figures for each source of time information (see my other message).