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 argument optional ones Date: Fri, 22 Apr 2022 08:23:24 +0300 Message-ID: <837d7hr8s3.fsf@gnu.org> References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5416"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manikulin@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 22 07:26:40 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 1nhloW-0001IH-Kt for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 07:26:40 +0200 Original-Received: from localhost ([::1]:51230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhloV-0003vF-9d for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 01:26:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhllR-0006gG-9I for emacs-devel@gnu.org; Fri, 22 Apr 2022 01:23:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhllP-00037X-Up; Fri, 22 Apr 2022 01:23:27 -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=/TNx58ZiuSLAFYQU67O5+9RuQC6/PhOySlh5tH8qGEM=; b=IVfvwcZYKdjV ++usmnPfVYoTqMo71DRY25Yy+9zFNUA43wc6hJm/E8dEsJJLMaQUs5daEdFTYMUZA5J9Y2tC36TVB 6g0qzajGJBDa6ZUCQhAp79lN+R5l/o2eW0f50m0zCzUnUV1qsLhgQAGLlogon3sOo7ZR02SY6/bv3 vc666seCHTzD3EucKNjsQtuxHvVyJdo10CpLtZah9LMlHl0FC167Z5PmF0s+s2WumUyPyMB4U8p5l 0uIVzEKiEztXqZ6sy8xTqwYeYC8Q3XkmvW80qkJ6oml00vPFyeZKA7DzwTMS6HslOKOR/5epNH8p9 zR1p572X34e4B46tjAJ8XA==; Original-Received: from [87.69.77.57] (port=1575 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 1nhllP-0002OS-Bj; Fri, 22 Apr 2022 01:23:27 -0400 In-Reply-To: (message from Paul Eggert on Thu, 21 Apr 2022 16:56:25 -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:288786 Archived-At: This discussion was moved from bug#54764, because it sounds like a general design issue is at stake here, and IMO we should discuss this before making any changes. I've removed the bug tracker and the Org and Gnulib lists from the addressees, because I think this is strictly an Emacs design issue. We can add them later if needed. For now, please refrain from adding them, to make the signal-to-noise ratio as best as possible. > Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > > don't we use time values for file timestamps? > > Yes, but file timestamps should use the resolution of the file system, > which in general is different from the resolution of the system clock. > That's a separate matter, which would be the subject of a separate > patch. For now we can stick with what we already have in that department. Sorry, I don't understand what that "for now" means. We are talking about the design of how time objects are represented in Emacs, so that design should cover all the possible uses of such objects, certainly those uses which we already know about. And that definitely includes file timestamps. So it is NOT a separate matter. It should be part of the discussion. > > And for Windows, all this does is measure the "resolution" of the > > Gnulib emulation of timespec functions on MS-Windows, it tells nothing > > about the real resolution of the system time values. > > If Emacs Lisp code (which currently is based on the Gnulib code) can see > only (say) 1-microsecond timestamps, then it doesn't matter that the > underlying system clock has (say) 1-nanosecond precision. Of course it > would be better for Emacs to see the system timestamp resolution, and if > we can get the time of day on MS-Windows to a precision better than 1/64 > second then I assume Emacs should do that. Once it does, the patch > should calculate a higher HZ value to tell users about the improved > resolution. You again are talking about the current implementation, whereas I would like to discuss the design and our goals. There's no problem whatsoever to provide high-resolution time stamps on MS-Windows, if we decide that this is what we want. The only reason we didn't do that until now is that it wasn't deemed important. > > if the "time resolution" determined by this procedure > > is different between two systems, does it mean that two time values > > that are 'equal' on one of them could be NOT 'equal' on another? > > Sure, but the traditional (HIGH LOW MICROSEC PICOSEC) representation has > the same issue. For example, if A's clock has 1 ms resolution and B's > clock has 10 ms resolution, A's (time-convert nil 'list) called twice > would return (say) the two timestamps (25184 64239 1000 0) and (25184 > 64239 1001 0) at the same moments that B's calls would return (25184 > 64239 1000 0) twice. A would say that the two timestamps differ; B would > say they're the same. Then it's a subtle bug in our current code that needs to be solved. > This sort of disagreement is inherent to how timestamp resolution works. I'm asking why timestamp resolution, as defined by HZ, at all matters in Emacs. Please answer this question before anything else, because it is IMO central to this discussion. In addition to the general cause you think this is important, please provide a list of use cases where you can show that using this definition of time resolution is important, and not using that would lead to problems. An alternative would be to decide on a unified resolution for time objects in Emacs, independent on what the underlying system does, and then use that everywhere. Why not do that? The next important question is how do we define "timestamp resolution" so that it covers all the uses, including file timestamps, time values that come from external systems, etc. (Granted, the simple alternative of using a single unified resolution that is fine-grained enough to cover all the known uses will solve this problem as well, and AFAIU solve it simply and cleanly.) I think we should only change our code after we conclude the discussion of the above-mentioned general issues, and agree on our goals and how we will implement those goals. Thanks.