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 EE92B00EYWKwCgEAbAwnHQ (envelope-from ) for ; Thu, 21 Apr 2022 09:14:21 +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 iP6aBk0EYWInTAEAG6o9tA (envelope-from ) for ; Thu, 21 Apr 2022 09:14:21 +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 10B7139A2 for ; Thu, 21 Apr 2022 09:14:20 +0200 (CEST) Received: from localhost ([::1]:51696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhR18-0005qC-Dh for larch@yhetil.org; Thu, 21 Apr 2022 03:14:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhQYE-0003hX-1F; Thu, 21 Apr 2022 02:44:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55334) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhQYC-0000Lb-US; Thu, 21 Apr 2022 02:44:24 -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=kFuZbCq12J8aAGzRAnVjGNXrXFVivgz1GbI1OLZKpWU=; b=GqJLpVG5YvqK mCFVG36AaxsRni1ILMooB1DCLdMx+P1PRFBgHKzWmodciIkgaB8q+2FMZxEbMtKthDCPysUe3WRTQ Qu3r6ieU3GN+kdcFLQ2d/G/Anj3ANrmxt7Y8qrZcxnIhOsKfA3DNujzQJpChpgXfHntQE1301PBlx Ps2+yK+tTS0mYt6btYOy1+PmmPloh99vDp80IZNwxZMDSk9BUtxrXJKWnxjt1pbBD9qOqUI9Pu7Bc m9WwreDm4QsKXWya9aafoVIVY8OfWg2dSn3ajmTXxJ+23jdRYnD0K8Gevaw/UIP3mE9m/Wkwt7OhX lQqEbPcG6dRTHaIykMxkfA==; Received: from [87.69.77.57] (port=4372 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 1nhQYC-0002OK-Dz; Thu, 21 Apr 2022 02:44:24 -0400 Date: Thu, 21 Apr 2022 09:44:18 +0300 Message-Id: <83y1zzq6kd.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu> (message from Paul Eggert on Wed, 20 Apr 2022 17:11:34 -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> 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=1650525260; 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=kFuZbCq12J8aAGzRAnVjGNXrXFVivgz1GbI1OLZKpWU=; b=cwo+ny7EWZ3xQCKbd3WhKzO7DPML+TwlLX7tqn474rJhbesGd9ITI79FyR+wuW7Bv5AIac LKNFI3ziOf5pVcB4FdlqDsNz5V/cXDPj+06RaL8txVWUWB4vodOcK6BVoLBGbYUqztlNWG 5If16i91/ql1xklYuyO+4f7QuNeQLYasipcekDfqwdyUpPyvgeWUbq390seksO6jFVyKd5 tvic41lvxP7eGjb2JQf4Q0Zl2lqpIcWutGYTTvST+fbp3Zy9KLY3h0cLCpnbMqwggy9Ifa Ogti2aymoRLE8FfeeBX+O81ed40xEahyxhDJz21xBmcjIKynJaUO2bjF3RZeyQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650525260; a=rsa-sha256; cv=none; b=jbqOQJatSuYg/RmwvH6RvlrTQ4dQfombbIsLmKjCplXG6oIF4kR0CLG+ennwabt4eX/Wjm aAkuPRgmh8BP2oo4TvfL/nakAerI6Hf9m3vnFsc7+urw/v104l1gRYBbaF7D3NmZ7J1UjB HoTjlFXb9/1mMNTj/1RWJBwXAZyEJp9D/w1cLcxwk3rzshgCFjL2j04BENYdSyXn43ZnLF uoVLzZW8EVwMsrxhAb2hN0fktR6VX3dJ3ryxFUsuZi1EmNJsIiLx7cTsLkOC2ghWrhCF8g CzU4Shg8Pld9meAkUKUJ9/hGHKlSPABZKD2gPe+kkJlsoZZ9rYYjtP8WBd2n0g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=GqJLpVG5; 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: -3.74 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=GqJLpVG5; 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: 10B7139A2 X-Spam-Score: -3.74 X-Migadu-Scanner: scn1.migadu.com X-TUID: 5K2VYi6/Ocao > Date: Wed, 20 Apr 2022 17:11:34 -0700 > Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > 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. That "first part", as I understand what you wanted, would be too long and tedious to examine, as the value changes once every 5500 lines. So I've modified the test program to print the time only when it changes, and here's the output: gettime_res returned 625000 ns time = 1650522863.038750000 time = 1650522863.054375000 time = 1650522863.070000000 time = 1650522863.085625000 time = 1650522863.101250000 time = 1650522863.116875000 time = 1650522863.132500000 time = 1650522863.148125000 time = 1650522863.163750000 time = 1650522863.179375000 time = 1650522863.195000000 time = 1650522863.210625000 time = 1650522863.226250000 time = 1650522863.241875000 time = 1650522863.257500000 time = 1650522863.273125000 time = 1650522863.288750000 time = 1650522863.304375000 time = 1650522863.320000000 time = 1650522863.335625000 time = 1650522863.351250000 time = 1650522863.366875000 time = 1650522863.382500000 time = 1650522863.398125000 time = 1650522863.413750000 > > 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. Then I think I don't understand the purpose of this measurement, as applied to Emacs Lisp. For example, you say that this is unrelated to file timestamps, but don't we use time values for file timestamps? 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. More generally, 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? And if so, wouldn't that mean Emacs Lisp programs will be inherently not portable? IOW, how do you intend to incorporate this "time resolution" into Emacs Lisp, and what will be affected by that value?