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: Mon, 25 Apr 2022 19:10:08 +0300 Message-ID: <83mtg9m9en.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> <83h76kq5c6.fsf@gnu.org> <9afbcc3d-b57c-b5bf-e4f6-52b352f99af8@cs.ucla.edu> <83bkwspa1r.fsf@gnu.org> <3008dea1-572b-9010-f3c4-15272145fd8a@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20293"; 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 Mon Apr 25 18:11:24 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 1nj1J5-0005Bc-RG for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Apr 2022 18:11:24 +0200 Original-Received: from localhost ([::1]:47256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nj1J4-0003AE-Lp for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Apr 2022 12:11:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nj1I9-0001ra-NQ for emacs-devel@gnu.org; Mon, 25 Apr 2022 12:10:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nj1I8-0006EW-Mu; Mon, 25 Apr 2022 12:10:24 -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=BkqAZTMJ9NPeasm2SDXfhjJVkttiWuAH2oDjishrs50=; b=jBZykcHujlGO w5eykYHF7I0dLcbgHpGfLPw5iDbploz5cilnhK4Yod8WGJ3IuDUj/9RTg/oXwBKqRjg6CijpJIHUW jIVpPUJn050oOPzJPQEs9c9mz8swf6CaL4x5/kLTcmrtEm5pYGGSheNKV3PcZ45vEzfjKrvaiO6T0 UISc0KmQQNkjgySBxaZAqDlZTs+a3GM0E37Q1J2kgizNaHjUAs6DOWZLhD/tLuZ5z65EQ+V8qO/HZ 10wXAbMxR+I49gOxo7VVqBNUhmvzuy0l+G513drBI/uIE3qjfE3qmh2uGvfe1YtsgieZCih/2PlMH l8FaJzcjC6xq4TWZwTbOEg==; Original-Received: from [87.69.77.57] (port=4003 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 1nj1I7-0000pV-Ae; Mon, 25 Apr 2022 12:10:24 -0400 In-Reply-To: <3008dea1-572b-9010-f3c4-15272145fd8a@cs.ucla.edu> (message from Paul Eggert on Mon, 25 Apr 2022 08:34:04 -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:288862 Archived-At: > Date: Mon, 25 Apr 2022 08:34:04 -0700 > From: Paul Eggert > Cc: manikulin@gmail.com, emacs-devel@gnu.org > > On 4/22/22 23:51, Eli Zaretskii wrote: > > >> There are Gnulib library functions to > >> deal with this sort of thing; it's not a new problem. > > > > Doesn't that slow down applications? > > Not significantly, no. file-attributes already has the file's filesystem > ID and timestamps so Emacs can easily cache that (it's a small cache > with only one entry per filesystem). There's no need to traipse through > the filesystem looking at other files. This is what coreutils does and > it works well in practice. It's not expensive and not that complicated. Sorry, I don't understand. Suppose the given Emacs session called file-attributes on only 1 file: how do we know the resolution of the file timestamps from that single file? The fact that a timestamp has N last digits zero says nothing at all about the resolution. > Your suggestion of maintaining a static table for known filesystem types > is a good one; we could do that to improve common cases. I would like to > take a look into doing this. Thanks, I think for starters we don't need anything else, like dynamic determination of the actual resolution. > If successful, it should improve coreutils > and other GNU apps even if Emacs makes no changes in this area. In the > meantime I'll withdraw the proposed changes that would cause Emacs to > communicate OS timestamp resolution to the user; that sort of thing can > wait until after I've had that look (assuming I ever find the time :-). Yes, it can definitely wait. I'd like first to see if my proposal is good enough, and if not, to hear really good reasons why not. > For example, if Emacs imports from the network a timestamp with three > digits after the decimal point, it should convert it to an internal > timestamp with millisecond resolution. I'm not sure this is TRT. What do you do if you get a timestamp whose fractional part looks like .123000 -- do you consider this to be millisecond resolution or microsecond resolution? If the latter, we'd get in trouble as result of trivial arithmetics on timestamps; if the former, you risk losing resolution for now good reason, just because the time stamp was too "round". > Conversely when sending a textual timestamp, Emacs should generate > only as many trailing digits as needed. It's very hard to keep only that many significant digits when working with fractional numbers.