From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: encode-time vs decode-time Date: Tue, 30 Jul 2019 12:54:21 -0500 Message-ID: <502b23f8-58ed-38ff-ae50-fae391129a10@cs.ucla.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="213501"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen , Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 30 19:54:43 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hsWKe-000tNz-7M for ged-emacs-devel@m.gmane.org; Tue, 30 Jul 2019 19:54:40 +0200 Original-Received: from localhost ([::1]:35414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsWKd-0007Ea-4f for ged-emacs-devel@m.gmane.org; Tue, 30 Jul 2019 13:54:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39462) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hsWKZ-0007EQ-2O for emacs-devel@gnu.org; Tue, 30 Jul 2019 13:54:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hsWKX-0001ge-Uz for emacs-devel@gnu.org; Tue, 30 Jul 2019 13:54:35 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:42174) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hsWKX-0001ay-Pl for emacs-devel@gnu.org; Tue, 30 Jul 2019 13:54:33 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4991E1626E2; Tue, 30 Jul 2019 10:54:29 -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 Plq0EJ-AlxSv; Tue, 30 Jul 2019 10:54:28 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7AA6B1626EB; Tue, 30 Jul 2019 10:54:28 -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 Sfz4ltpG17pm; Tue, 30 Jul 2019 10:54:28 -0700 (PDT) Original-Received: from [192.168.0.8] (ip72-206-6-38.fv.ks.cox.net [72.206.6.38]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2B8991626E2; Tue, 30 Jul 2019 10:54:28 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239039 Archived-At: On 7/30/19 6:37 AM, Lars Ingebrigtsen wrote: > a number of seconds can also be used as a duration, but > that's a different matter. The issues are not that independent. Just as a Lisp timestamp like 1564500522 can be treated as absolute (2019-07-30 15:28:42 UTC) or relative (1564500522 seconds duration), a calendrical value like (42 28 15 30 7 2019 2 nil 0) can also be treated as an absolute time (the same absolute time, in this example) or as a relative time (using calendrical arithmetic). > adding an optional parameter to `decode-time' to also make it > include sub-second time in the decoded time structure it returns (also > as previously discussed) may be the right thing to do. However, I've > grepped through the sources now for usages of decoded time, and it kinda > looks to me like adding a ninth slot in decoded time structures would > probably not break anything. Any ninth slot should be a numerator-denominator pair if it's nonzero, to avoid losing precision. Something like this: (decode-time '(1564504076643563153 . 1000000000) t) => (56 27 16 30 7 2019 2 nil 0 (643563153 . 1000000000)) > this is very confusing indeed To some extent the confusion is inherent: there are a lot of useful ways to represent and manipulate times, and people unfamiliar with the issues will find this complexity confusing. That being said, it would be good to simplify the Emacs API for time without significantly hurting functionality or compatibility. So, how about this idea. First we go along the lines of your suggestion, and change decode-time to return a ninth slot with a numerator-denominator pair that preserves all the precision of its argument. Second, we change (encode-time TIME t) so that it also preserves all the precision of its argument. This will cause (encode-time (decode-time TIME) t) to return a value equivalent to TIME, which will simplify roundtripping.