From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id KIyjFvc2YmLPUgEAbAwnHQ (envelope-from ) for ; Fri, 22 Apr 2022 07:02:47 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cLChFfc2YmK2ygAAG6o9tA (envelope-from ) for ; Fri, 22 Apr 2022 07:02:47 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C09036CF1 for ; Fri, 22 Apr 2022 07:02:46 +0200 (CEST) Received: from localhost ([::1]:53242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhlRN-0000we-Us for larch@yhetil.org; Fri, 22 Apr 2022 01:02:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35716) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhlQj-0000wC-SG; Fri, 22 Apr 2022 01:02:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51394) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhlQi-0008Rr-Eh; Fri, 22 Apr 2022 01:02:04 -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=hBiJKmqB+A/79rvFsw1Mbfhgrvxhlhvp/A1V/2V632I=; b=iFA73t+xChrM l5xF+fm94PJeUWZJ1ObfKSsFZSLR085S9LwAOHs3IJ6hb+AAmcMgNTDH2LW+EhzW+78unrEyp/VY/ D4+3MVeS3STLIto7HVS63t9BmIvb7JHurv9x5+p3gcZhQZLTR8O4ynS0UP6HlVCdvPSd2J+2iuhnO P05GBXz0Bh6iC6OGjqLQaY80gdkdkp41ByF0kYE1DB8/bu2dSMeysgEFY01t2mewNxgCtMVAK8QjR xUXKX0SaOWEWxhsRqdh378j58vAdDzeLwsiDKWiX9pI8izLs+bn2e08tEVbnuukAda4TMnfqc/SVI NM+H3SPUmAXDuYF5P0ZCmw==; Received: from [87.69.77.57] (port=4163 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 1nhlQg-0007Pn-SB; Fri, 22 Apr 2022 01:02:03 -0400 Date: Fri, 22 Apr 2022 08:01:58 +0300 Message-Id: <838rrxr9rt.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: (message from Paul Eggert on Thu, 21 Apr 2022 16:56:25 -0700) Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones 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> X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650603767; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=hBiJKmqB+A/79rvFsw1Mbfhgrvxhlhvp/A1V/2V632I=; b=U4KOq2H5fdV0qu670Iv87N6zApDjLO21drtaFjO9uAl9ptEgkLVQKyRhqpWyo1sDgAqtBa PUmPK7DYhszceFc+R3yyamyhSM30OUKh8C4/Tm9ivavL1qvrJ/fTPRGp+tYC/VHyLV2uc+ rGmQOfH7yxBrIJ73ak5eld+AAyRh04r9cLbhT6ZlyjwTIWDF03sSToA4STWn42hUl7hfaD ZQPDrkKbjvQO0U8vxvIU59CUHdhBmGm7s0wUkcleIykRg8dd2FQwBdaiagzTpNv3M1CoI3 Nl6/vriy6ooyY+MvkpU8hpJU+Of/WUn+jEqJlHv5AY5Hr4f8PCJutf/gzOgLQw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650603767; a=rsa-sha256; cv=none; b=NS8H6fMjv+wTUFwGFtnAFrNXtj7PyXbR8DUjcE93HulCQK7TZzKTAnDVyuG7/n47MnB2Pl YxHOCf+OdOaFcM6TLdhCtTVraG/yBq2IDQWP4j/G2UPMo/wXCpRF/DAS9IUbrLeKOscEeB 7YmAh9ywti4D/h9S3UOb/LJtC0fb2zWGy+aTkAEJb2NhgnGmw26MOGzuDDQqHrR0xeIKe9 VONihIt3eExr7E35qBP/7fgeg+yKYkxRK+RQSd8JP915p7Mbn2znaq7J49I9K8K9sZdvb7 hjwux0qjHb3VLXzrYiRWW0MgJe/cf4GAy/ywbocBIYpRNvKvqdVkYFrhWgYXFA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=iFA73t+x; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -9.53 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=iFA73t+x; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: C09036CF1 X-Spam-Score: -9.53 X-Migadu-Scanner: scn0.migadu.com X-TUID: V3Nlsisp1y8c > Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > What appears to be happening here is that the MS-Windows native > timestamp resolution is 1/64th of a second, and your system's clock is > offset by 0.0075 s from an integer boundary. I.e., the timestamps in > increasing order are: > > ... > 1650522862 + 62/64 + 0.0075 = 1650522862.976250 > 1650522862 + 63/64 + 0.0075 = 1650522862.991875 > 1650522863 + 0/64 + 0.0075 = 1650522863.007500 > 1650522863 + 1/64 + 0.0075 = 1650522863.023125 > 1650522863 + 2/64 + 0.0075 = 1650522863.038750 > ... > > and the system clock never returns a timestamp on an integer boundary > (i.e., tv_nsec is never zero). > > We have two options to express this as Emacs timestamps: > > (1) We can keep information about resolution but lose information about > time, by using a resolution of 15.625 ms (i.e., 1/64 s) and truncating > timestamps to the nearest 1/64 second. This would generate the > following (TICKS . HZ) timestamps: > > ... > (105633463230 . 64) = 1650522862 + 62/64 = 1650522862.968750 > (105633463231 . 64) = 1650522862 + 63/64 = 1650522862.984375 > (105633463232 . 64) = 1650522863 + 0/64 = 1650522863.000000 > (105633463233 . 64) = 1650522863 + 1/64 = 1650522863.015625 > (105633463234 . 64) = 1650522863 + 2/64 = 1650522863.031250 > ... > > (2) We can keep information about time but lose information about the > resolution, by using a resolution of 0.625 ms (i.e., HZ = 1000000000 / > 625000 = 16000). (We use 0.625 ms because it is the coarsest resolution > that does not lose time info.) This would generate the following (TICKS > . HZ) timestamps: > > ... > (2640836580762 . 1600) = 1650522862 + 1562/1600 = 1650522862.976250 > (2640836580762 . 1600) = 1650522862 + 1587/1600 = 1650522862.991875 > (2640836580762 . 1600) = 1650522863 + 12/1600 = 1650522863.007500 > (2640836580762 . 1600) = 1650522863 + 37/1600 = 1650522863.023125 > (2640836580762 . 1600) = 1650522863 + 62/1600 = 1650522863.038750 > ... > > The patch does (2), and this explains the "gettime_res returned 625000 > ns" in your output. > > It shouldn't be hard to change the patch to do (1), if desired. I doubt > whether users will care one way or the other. These are very fine details of the implementation, which we can get back to later. I would like first to discuss the more general issue of basing the design on such tests, and on the notion of "clock resolution" as expressed by these tests. TBH, what you propose makes no sense to me for now, and for some reason you didn't answer my more general questions about that, but instead preferred to respond only to their secondary aspects. At this point, I object to any changes in this area until we discuss the more general aspects of this design and decide whether we agree with it. Such a discussion should be on emacs-devel, so I move this there; please continue the discussion there. Thanks.