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 11:22:11 -0700 Organization: UCLA Computer Science Department Message-ID: 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> <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="26385"; 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: manikulin@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 22 20:23:44 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 1nhxwW-0006h0-Dn for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 20:23:44 +0200 Original-Received: from localhost ([::1]:56254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhxwV-0000sS-6h for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 14:23:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhxv8-0006rK-US for emacs-devel@gnu.org; Fri, 22 Apr 2022 14:22:18 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38532) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhxv6-0003mt-4F; Fri, 22 Apr 2022 14:22:18 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC1E81600C0; Fri, 22 Apr 2022 11:22:12 -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 4PWU9axpskxO; Fri, 22 Apr 2022 11:22:11 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C70F91600C2; Fri, 22 Apr 2022 11:22:11 -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 eazVMgp18KVJ; Fri, 22 Apr 2022 11:22:11 -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 9AC5D1600C0; Fri, 22 Apr 2022 11:22:11 -0700 (PDT) Content-Language: en-US In-Reply-To: <837d7hr8s3.fsf@gnu.org> 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:288803 Archived-At: On 4/21/22 22:23, Eli Zaretskii wrote: > 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. An example of when this matters is that GNU 'ls' needs to know whether a file timestamp is in the future because 'ls -l' uses a different textual format for future timestamps than it does for recent-past timestamps, as a visual cue to the user that the user has a clock skew problem that can screw up GNU 'make' and similar programs. For example, if I run the shell script: touch now touch --date=@$(date +%s.%N | sed 's/........$/99999999/') future ls -l future now Here's the output I should see, because 'future' has a timestamp in the future: -rw-rw-r--. 1 eggert eggert 0 Apr 22 2022 future -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now However, if GNU 'ls' got the time of day with lower resolution than it got file timestamps, it would use the wrong textual format for a recently-created file's timestamp, because it would compare a lower-res time-of-day like 1650651200.73 to a higher-res file timestamp like 1650651200.734627956 that was generated before the current time. The above example would therefore generate the incorrect output: -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 future -rw-rw-r--. 1 eggert eggert 0 Apr 22 11:13 now When Emacs needs to do something like what GNU 'ls' does, it can have the same issue. Admittedly this is not the most important issue on Emacs's plate. Still, Emacs should do a good job and be compatible with other GNU tools. >> 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. It matters for applications like GNU 'ls' as described above. It also matters for applications that want to display a timestamp accurately, but without excess information that bogs down performance and implies more precision than is actually present. For example, current GNU 'date' can use a format '%s.%-N' that outputs the current time without excess trailing zeros in the subseconds part. Emacs should be able to do something similar. > 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. Doing what GNU 'ls' does, and what GNU 'date' does, are two use cases. Another example is doing what GNU 'cp -u' does when comparing file timestamps. I expect there are others. > 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? We've already done that in Emacs with the (TICKS . HZ) representation. The obvious fix here would be to use better time-of-day primitives on Microsoft Windows, in particular, primitives that don't use a syncopated clock. (By "syncopated clock" I mean one that doesn't beat on 1-second boundaries.) This would be simpler than adding support for syncopated clocks to the Emacs timestamp format, as syncopated clocks are too much trouble to document and implement and would complicated too much code for too little benefit. Besides, a precision of only 1/64 second on the time of day is not adequate for quite a few applications these days, so this issue of low-resolution time-of-day should be fixed on MS-Windows regardless of how Emacs represents timestamps internally. >> > 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. I meant that we can stick with what we currently do for file timestamps, which is to generate Emacs Lisp timestamps with a greater resolution than what the file timestamps actually have. This loses information about the resolution, but does not lose information about the time values. This doesn't mean I'm a fan of the current situation with file timestamps. It means only that we can address the current-time problem in one patchset, and the file timestamp issue in a later patchset. It will be better to separate the solutions in this way, than to try to solve the problem all at once. > It should be part of the discussion. OK.