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:52:47 -0700 Organization: UCLA Computer Science Department Message-ID: <9afbcc3d-b57c-b5bf-e4f6-52b352f99af8@cs.ucla.edu> 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> <83h76kq5c6.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="11044"; 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 23:53:38 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 1ni1Dd-0002kY-L9 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 23:53:37 +0200 Original-Received: from localhost ([::1]:36272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ni1Dc-0002Ld-52 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 17:53:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40708) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni1Cw-0001eo-Ao for emacs-devel@gnu.org; Fri, 22 Apr 2022 17:52:54 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni1Ct-0000IU-VB; Fri, 22 Apr 2022 17:52:53 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id AAE3216005E; Fri, 22 Apr 2022 14:52:48 -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 uYL-phgwm7Ya; Fri, 22 Apr 2022 14:52:47 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8897B1600C2; Fri, 22 Apr 2022 14:52:47 -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 rMtbFEsVVpyj; Fri, 22 Apr 2022 14:52:47 -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 5DC0116005E; Fri, 22 Apr 2022 14:52:47 -0700 (PDT) Content-Language: en-US In-Reply-To: <83h76kq5c6.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:288810 Archived-At: On 4/22/22 12:35, Eli Zaretskii wrote: > to do such comparisons correctly we need to > have each time object state its resolution, otherwise you will never > know how to compare them. Yes, quite true. > That resolution cannot be possibly determined by > measuring the system clock resolution, because doing that will at best > provide the figure for one class of time objects. Also quite right. Emacs needs to determine the timestamp for each class of objects as best it can. > the current implementation of measuring that resolution > fails miserably on MS-Windows, producing a very incorrect value.) It's a correct value for what it's measuring, which is (roughly) the number of digits needed to express each timestamp precisely. It's not correct for a different measure, namely the timestamp resolution, which it sounds like is what you'd prefer. As I mentioned in it shouldn't be hard to support this other measure, and I can look into doing that. > What is the plan for other kinds of time objects? For example, how > would we determine the resolution of file times We could do what Coreutils does, in commands like 'cp -u' that sample timestamps in each file system to determine resolution. This approach works well enough in practice. There are Gnulib library functions to deal with this sort of thing; it's not a new problem. > as your examples show, that kind of timestamp is the one that needs > resolution information much less than the other ones. I don't see how the examples show that. > Please don't be obsessed with MS-Windows. There's no obsession here on my part. MS-Windows appears to be the only platform where current-time generates such low-resolution timestamps, or generates syncopated timestamps, and that's why discussion has naturally centered on that platform. > examples you gave deal with > file timestamps, and you explained that we do risk losing information > there. Yes, and Emacs currently loses all information about file timestamp resolution, on all platforms. It would be better for Emacs to report as much of that information as it easily can. This could be done by using the Gnulib library functions suggested above. Reporting this information is better than losing it. > even if we consider the (contrived) example with 'date' > important for some reason, the result will be incorrect there for a > couple of milliseconds, and thereafter will become correct, and who's > to know, or care, that it was incorrect for those 2 milliseconds? Yes, most users don't notice timestamps being a little off. And these users surely won't care whether we improve the timestamps to be more accurate. But that doesn't mean that it's a bad idea to improve timestamp quality.