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:51:12 +0300 Message-ID: <83bkwspa1r.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> <837d7hr8s3.fsf@gnu.org> <83h76kq5c6.fsf@gnu.org> <9afbcc3d-b57c-b5bf-e4f6-52b352f99af8@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20868"; 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 Sat Apr 23 08:54:05 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 1ni9ef-0005JD-IA for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Apr 2022 08:54:05 +0200 Original-Received: from localhost ([::1]:40038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ni9ee-0006AW-07 for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Apr 2022 02:54:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni9bu-0005KJ-UX for emacs-devel@gnu.org; Sat, 23 Apr 2022 02:51:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni9bt-0004lP-Me; Sat, 23 Apr 2022 02:51:13 -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=x/2Z2k7HCmLoweqvDO8/qotVQY9slsDf71UzybxVR+o=; b=SAz8ETbmlv08 byBCRf+ix7V5WN2blZ8+yTPoinvHL3oYzD28cz1piRp4U3/1r+Quj1CehwHXF0IYsDM8179DolANT 1IjpsWzeCbG0rat42vsU2lkH7P4TsbldDWs5leDugT5jDAIAnQ86h1YhGmnPCFuUIQkA+wU0GNwso l9g4CbGSltCB7p6AwDwspSpLuSKA6jozGBQAkd1E6tJSFvPuNx/L/T/oFP5XpOYvb7Xuryf1Pth9/ npPoJXltJXRQ/sdr7lgQLS8fbMA0wGox0VmcFnK5V4Bz09iTIVYLt3RJB4f+OGH5tmDZpBR8Cq14c A2Et/gkyJ+fNYOFijlhQjA==; Original-Received: from [87.69.77.57] (port=2759 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 1ni9bt-0006PG-6J; Sat, 23 Apr 2022 02:51:13 -0400 In-Reply-To: <9afbcc3d-b57c-b5bf-e4f6-52b352f99af8@cs.ucla.edu> (message from Paul Eggert on Fri, 22 Apr 2022 14:52:47 -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:288813 Archived-At: > Date: Fri, 22 Apr 2022 14:52:47 -0700 > Cc: manikulin@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > > > 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 question is: how feasible is that? See below; my current conclusion is that it is not feasible in general. > > 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. Doesn't that slow down applications? How many time stamps should we need to sample to determine a good estimation? The sampling should be separate for each filesystem, but do we have information about the file's filesystem in all cases? What about the cases of different accuracies for different times (creation, modification, access)? These questions need to have practical reasonable answers before we decide this is tractable. I also question the need for Emacs to do what few other applications do (GNU Coreutils are an exception rather than the rule here, AFAIK), given the tremendous complexities this will require from us. For example, 'cp' specifically deals with copying many files, but that's not what Emacs does in most applications where it cares about comparing file timestamps with some other class of timestamps. So where 'cp' can sample file timestamps of the files it is copying, Emacs will be unable to do so, without costly traversing directories it has no business of looking at, and for which it may not have access rights in the first place. > > 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. The 'date' example is IMNSHO artificial and not important, except for people whose special interest is in time APIs. > > 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. That's what I'm saying: don't center the discussion on Windows. The problem is much more general and broad, see above and below. > > 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. Please point to those function so they could be studied, or describe what they do here. I don't see how this could be reasonably solved in general, even for file timestamps. And what about other sources of time data? For example, timestamps from other systems (like in your NTP example), timestamps that are reported by Tramp functions, etc.? How do we reliably estimate the accuracy of those? Once again, without a comprehensive plan that is capable of covering all the sources of time information we routinely deal with in Emacs, I don't think we should make any significant changes in our time-API infrastructure nor in the structure of our time representation objects. > > 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. It isn't a bad idea, but if the complexity it introduces into the way Emacs handles time information is too high and the benefits are too low, then we shouldn't add such complexities to Emacs, because the benefits won't justify the costs. So far I'm not convinced it is feasible to solve these issues in Emacs without introducing unreasonable complexity, and even that will only provide a partial solution. Once we understand which part(s) of this can be solved and at what cost, we could perhaps come up with simplified solutions that avoid most of the costs, such as using a static database of timestamp accuracies for important classes of timestamps. But we aren't there yet, and it is so far premature to discuss these specifics.