From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id oGS+GVfvYWImYgAAbAwnHQ (envelope-from ) for ; Fri, 22 Apr 2022 01:57:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SCCwGVfvYWJ+cAAAauVa8A (envelope-from ) for ; Fri, 22 Apr 2022 01:57:11 +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 861C21B9DD for ; Fri, 22 Apr 2022 01:57:10 +0200 (CEST) Received: from localhost ([::1]:35802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhgfd-0000Bn-7n for larch@yhetil.org; Thu, 21 Apr 2022 19:57:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhgf8-00008v-V9; Thu, 21 Apr 2022 19:56:38 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41382) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhgf6-0000C4-OX; Thu, 21 Apr 2022 19:56:38 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 04779160090; Thu, 21 Apr 2022 16:56:32 -0700 (PDT) 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 BHLNFG0lx9sW; Thu, 21 Apr 2022 16:56:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0794B16009A; Thu, 21 Apr 2022 16:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 l_6jBZbcvm6A; Thu, 21 Apr 2022 16:56:30 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D9EFF160090; Thu, 21 Apr 2022 16:56:30 -0700 (PDT) Message-ID: Date: Thu, 21 Apr 2022 16:56:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Content-Language: en-US To: Eli Zaretskii 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> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <83y1zzq6kd.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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-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=1650585431; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=uEhH75yNC+CB+PvlEprnR+O0DsWsv0wQkX+gYcAxaQk=; b=jyMD0pxkE6ueSHoHCXB/isRLiHXq41swwesGSyLsJfth/B+M2yCfx/3t8agu6XBVZuOmJG lFYBQ1UX/In7raNla2oQkbfsFDvXYYrChozvUlpHCPuCeBfQ2oeAijWy2Qquh2Mu9AM37D 9vUnzDMKQXk9wp+tD/1AcRYTqN3RujL8yEb6UgBLhkdC89JfiVljXjODAigFrLo29drTv/ p7tn+k2nkGrK3RVYgAS+ZgHVwsPMTW41yJcc/GhzyEvMIMAAflTXMN8R1KcAeNgEck1YNY IU/CiX+PGAChdt7eVll9MjS8IuoCW5jC+QyZboba0bvzcjpnsX0NFIlXSEfqeg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650585431; a=rsa-sha256; cv=none; b=N8R9dx+K7SHWQKeZPtO/g4suxkcYUPM60RD2RPSNYnVKFMzBryjz16Y7HQU3sTh3BbY1IV uTsG9S8D3pRo6Ty6MESHxhmZCvdIq+T928FMs0r1/9vYWKZ3Lmb424LwCcN6mQABUWjgzZ Zb8k2X/XKt6uOAvfozcxTBLMT6BOR2Yr2KO6rXfQuLt8TkENSg9tCgxEmDIVGkW1Sxe7f2 YPp2+ZJSl17a2jeWr51zIoiEzthGY+rPjoJflntJmD8sAMwPbnTEhbICzxJMYqvxKLEFCY BFOuxdhrZiwvZrABEzM/jkqAHV0rSoMSzZo1kRsxnR7w3NRdu2nuVoR4wSa6hw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; 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: -3.03 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; 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: 861C21B9DD X-Spam-Score: -3.03 X-Migadu-Scanner: scn1.migadu.com X-TUID: +5HQwkwZkfZM 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. > don't we use time values for file timestamps? Yes, but file timestamps should use the resolution of the file system, which in general is different from the resolution of the system clock. That's a separate matter, which would be the subject of a separate patch. For now we can stick with what we already have in that department. > And for Windows, all this does is measure the "resolution" of the > Gnulib emulation of timespec functions on MS-Windows, it tells nothing > about the real resolution of the system time values. If Emacs Lisp code (which currently is based on the Gnulib code) can see only (say) 1-microsecond timestamps, then it doesn't matter that the underlying system clock has (say) 1-nanosecond precision. Of course it would be better for Emacs to see the system timestamp resolution, and if we can get the time of day on MS-Windows to a precision better than 1/64 second then I assume Emacs should do that. Once it does, the patch should calculate a higher HZ value to tell users about the improved resolution. > if the "time resolution" determined by this procedure > is different between two systems, does it mean that two time values > that are 'equal' on one of them could be NOT 'equal' on another? Sure, but the traditional (HIGH LOW MICROSEC PICOSEC) representation has the same issue. For example, if A's clock has 1 ms resolution and B's clock has 10 ms resolution, A's (time-convert nil 'list) called twice would return (say) the two timestamps (25184 64239 1000 0) and (25184 64239 1001 0) at the same moments that B's calls would return (25184 64239 1000 0) twice. A would say that the two timestamps differ; B would say they're the same. This sort of disagreement is inherent to how timestamp resolution works. It doesn't matter whether the timestamps are represented by (HIGH LOW MICROSEC PICOSEC) or by (TICKS . HZ); users will run into the same problem in both cases.