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 22:35:21 +0300 Message-ID: <83h76kq5c6.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31329"; 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 21:36:20 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 1nhz4m-00080D-0h for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 21:36:20 +0200 Original-Received: from localhost ([::1]:48034 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhz4k-0003Qq-IE for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Apr 2022 15:36:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52062) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhz3s-0002iV-NH for emacs-devel@gnu.org; Fri, 22 Apr 2022 15:35:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38732) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhz3r-0006I4-PF; Fri, 22 Apr 2022 15:35:23 -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=E9NIUGdK0NcQuUtBROHH7gjHVNGZjiXsiXabbZvJhLo=; b=jdPR7TuYjJmN bJxdBZxrxk1gHvf9s6t1UXId2HsY7v0PJu/oIsywHwjl4eS/Q6Qmtv+sADy1cM8wZQV5KuRD/e4CY 9t+knBRNArsr00giVKi3cw+mMozwoUN5pZpI2v7S6qKNI858Mvc8d7fqJ5bx8mdMsKIOpGd+Muool CpPbsGSLurym7XDzUxCywCaaoCBdJXSILNGHvpykoaT6qzVHjnSFe6n5A6YRLrimLAa9//bALxjGa iZ49hGXxYvrq0BCxfdGak7Rxq0geJmRPzGUavMWO30TvrEh7aqMb4sL4ZZTYIuJh6D/cdm6j3LrO1 r7DwIATIdRBBlXx0ctBY/A==; Original-Received: from [87.69.77.57] (port=4662 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 1nhz3q-0001GA-FT; Fri, 22 Apr 2022 15:35:23 -0400 In-Reply-To: (message from Paul Eggert on Fri, 22 Apr 2022 11:22:11 -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:288805 Archived-At: > Date: Fri, 22 Apr 2022 11:22:11 -0700 > Cc: manikulin@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > > > 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. It is ironic that you wanted to leave file timestamps alone, but almost all of the examples you show are related to comparing file timestamps with other timestamps. I think there's no problem whatsoever in what we do as long as we compare times whose source is the same, i.e. has the same resolution. For example, even with the 15.6 msec resolution of the system time functions on MS-Windows, we have no problems with stuff like timers in Emacs -- we just lose the capability of reliably running timers with time intervals smaller then the resolution. But we never err about which system time is later. It is only when comparing timestamps from different sources that the problem might appear. But to do such comparisons correctly we need to have each time object state its resolution, otherwise you will never know how to compare them. We cannot simplify by assuming that one of them is more accurate and use the resolution of the less accurate one, because such assumptions will never hold. For example, while it's true that file timestamps are more accurate on MS-Windows than the system clock, sometimes it's the other way around: when using FAT32 volumes, the file time resolution is 2 sec (and, btw, that affects GNU/Linux systems as well, when they use such filesystems). Moreover, some filesystems have different time resolution for different times (creation, modification, access) on the same type of volume. So, then, to do this stuff correctly, we need to assign resolution to each time object. 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. ("At best" because, as we saw, the current implementation of measuring that resolution fails miserably on MS-Windows, producing a very incorrect value.) What is the plan for other kinds of time objects? For example, how would we determine the resolution of file times -- do we have the technology of telling that for each time field on each type of filesystem we want to support? And what about other types of time objects, for example, those that come via Tramp from remote hosts -- how do we measure or otherwise tell their resolution? Without having some plan to obtain reliable resolution figures in all these and other important use cases, it makes no sense to me to introduce resolution for just one kind of timestamp, especially since, as your examples show, that kind of timestamp is the one that needs resolution information much less than the other ones. > 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. Please don't be obsessed with MS-Windows. The issue is much more general and acute, as I tried to explain above. What is the plan for resolving the more general issue given the state of our knowledge and technology, and the variety of sources of time data, each one with its own resolution? Is this at all feasible enough to even try? It makes no sense to me to start if we cannot solve this at least in most cases. > 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. I don't understand this. Two out of 3 examples you gave deal with file timestamps, and you explained that we do risk losing information there. Given this importance of file timestamps, without having some plan of solving that problem, the rest is actually a moot point, because 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? IOW, as long as we are talking about timestamps from the same source, in this case from the system clock, the problem is so infinitesimally small that it's almost academic, not a practical one. So it makes little sense to me to make changes just for that one class of timestamps without a clear plan for the other classes.