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.bugs Subject: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Date: Wed, 20 Apr 2022 10:23:26 +0300 Message-ID: <83fsm8tdzl.fsf__4961.91431754909$1650439468$gmane$org@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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 20 09:24:22 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 1nh4hJ-00071O-EG for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Apr 2022 09:24:21 +0200 Original-Received: from localhost ([::1]:41516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nh4hI-0005fT-9k for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Apr 2022 03:24:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nh4h0-0005dc-SU for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 03:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51032) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nh4h0-0002YE-Hs for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 03:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nh4h0-0003e1-Cz for bug-gnu-emacs@gnu.org; Wed, 20 Apr 2022 03:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Apr 2022 07:24: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.165043943813999 (code B ref 54764); Wed, 20 Apr 2022 07:24:02 +0000 Original-Received: (at 54764) by debbugs.gnu.org; 20 Apr 2022 07:23:58 +0000 Original-Received: from localhost ([127.0.0.1]:44929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nh4gv-0003di-UT for submit@debbugs.gnu.org; Wed, 20 Apr 2022 03:23:58 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nh4gf-0003dB-F4 for 54764@debbugs.gnu.org; Wed, 20 Apr 2022 03:23:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57686) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nh4gZ-0002W3-8j; Wed, 20 Apr 2022 03:23:35 -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=wlthkeR7RqKQy/pkSHwXP1gTLxzu0zYrPFFZJXLgdyA=; b=O8oWjEvG/oOO utXtnrdD7NG+OPSPHU2GJw5vyWduXQs0UlL2bg0OGCmmobVVAB6ghS/uUdZbISQNisXL36gVQjUcQ RIc36XS2IqdJNQ/02s+pw4yD4FnpAEb0gNNw4z6ri0W/J/zpHm8p2HhJ7r7Ni7xaZJ0V7Pc/zYGdz BvCEx4MhiTpsNf6oP0lTfWZmbrM3l+G/jL6UZaUbskq3p2c1NteHNgsA996GXe1Q2k7aupVhiAs9q AWgaLZEZ7n9QZTqGUflrdzsQuI2BWui9FdjR6Sy+62oDTTfczvCKpv/ElpRglSm/4sEKI+4vBHWMw FKxJi/hu4YkCEV06HuWYWg==; Original-Received: from [87.69.77.57] (port=4723 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 1nh4gY-0004Xj-NB; Wed, 20 Apr 2022 03:23:35 -0400 In-Reply-To: <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu> (message from Paul Eggert on Tue, 19 Apr 2022 15:22:29 -0700) 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:230276 Archived-At: > Date: Tue, 19 Apr 2022 15:22:29 -0700 > Cc: manikulin@gmail.com, emacs-orgmode@gnu.org, 54764@debbugs.gnu.org > From: Paul Eggert > > On 4/18/22 22:50, Eli Zaretskii wrote: > >> * admin/merge-gnulib (GNULIB_MODULES): Add gettime-res. > >> * lib/gettime-res.c: New file, copied from Gnulib. > >> * lib/gnulib.mk.in, m4/gnulib-comp.m4: Regenerate. > > Is this known to support MS-Windows correctly? > > I haven't tested it on that platform, though I expect it to work since > it relies only on current_timespec and Emacs already uses that. > > I just now added some test cases to Gnulib for it; see the patch in the > first attachment. You can try these tests in your environment by running > './gnulib-tool --test gettime-res' in the Gnulib source directory. Or > you can save time by running './configure; make check' in the directory > represented by the second attachment, which is a compressed tarball > containing the output of './gnulib-tool --create-testdir --dir > test-gettime-res gettime-res'. Thanks, the test-gettime-res test says "gettime_res returned 625000 ns", which is a strange number: it doesn't fit any MS-Windows system time resolution figure I know about. Do you happen to know what does this number represent, and why it is the result of gettime-res.c when it runs on MS-Windows? AFAIK, the basic resolution of MS-Windows time stamps is 100 ns, so using the above much larger number seems to hint at some significant loss of information. If the goal of this future changeset is to make Emacs time stamps more fine-grained, it would be a shame not to have the 100-ns resolution on MS-Windows.