From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Date: Wed, 20 Apr 2022 17:11:34 -0700 Organization: UCLA Computer Science Department Message-ID: <33fb24fb-282b-cc13-a597-e7b63f19982d__25031.9285130658$1650499940$gmane$org@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33761"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Cc: emacs-orgmode@gnu.org, manikulin@gmail.com, bug-gnulib@gnu.org, 54764@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 21 02:12:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nhKQe-0008cB-DC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Apr 2022 02:12:12 +0200 Original-Received: from localhost ([::1]:57498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhKQd-0000ju-Bj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Apr 2022 20:12:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60760) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhKQU-0000hx-RK for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 20:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54000) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhKQU-0005Qi-IV for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 20:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nhKQU-0004TA-EE for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 20:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Apr 2022 00:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54764 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 54764-submit@debbugs.gnu.org id=B54764.165049990317133 (code B ref 54764); Thu, 21 Apr 2022 00:12:02 +0000 Original-Received: (at 54764) by debbugs.gnu.org; 21 Apr 2022 00:11:43 +0000 Original-Received: from localhost ([127.0.0.1]:47897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhKQB-0004SF-7J for submit@debbugs.gnu.org; Wed, 20 Apr 2022 20:11:43 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhKQ9-0004Rx-3j for 54764@debbugs.gnu.org; Wed, 20 Apr 2022 20:11:41 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A943F16007E; Wed, 20 Apr 2022 17:11:35 -0700 (PDT) Original-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 A8sIkJDyfe9u; Wed, 20 Apr 2022 17:11:34 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E112F1600D4; Wed, 20 Apr 2022 17:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-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 n67FhqoSZ0Yz; Wed, 20 Apr 2022 17:11:34 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A53E816007E; Wed, 20 Apr 2022 17:11:34 -0700 (PDT) Content-Language: en-US In-Reply-To: <83czhbsgc2.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:230340 Archived-At: On 4/20/22 12:30, Eli Zaretskii wrote: > I see the time samples change in jumps of 15 msec. Could you give the first part of the output? I would like to see what the the samples are jumping from and to, and how often they jump. Something like the following is what I'd hope to see from the first lines of the output of 'gllib/test-gettime-res x'. What are you seeing? gettime_res returned 15625000 ns time = 1650496481.515625000 time = 1650496481.531250000 time = 1650496481.546875000 time = 1650496481.562500000 time = 1650496481.578125000 time = 1650496481.593750000 time = 1650496481.609375000 time = 1650496481.625000000 time = 1650496481.640625000 time = 1650496481.656250000 > Which is expected > on MS-Windows, given the scheduler time tick, but what does that have > to do with the system's time resolution? The resolution of Elisp's (time-convert nil t) is determined by the smallest nonzero gap between timestamps that are returned by C's current_timespec. This is the system time resolution as far as Elisp is concerned, because Elisp cannot return the current time at a finer resolution than what current_timespec gives it. This resolution is not necessarily the same as the time resolution of the motherboard clock, OS high-res timestamp, file timestamps, etc. > And how is the 0.625 msec > number reported by the program obtained from those samples? Use the largest resolution R ns consistent with the samples, such that 1000000000 is an integer multiple of R so that timestamp computations are exact.