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, 6 Aug 2019 18:02:30 -0700 Organization: UCLA Computer Science Department Message-ID: <68d24d6a-d427-baef-27e9-ea1cbbd64c18@cs.ucla.edu> References: <502b23f8-58ed-38ff-ae50-fae391129a10@cs.ucla.edu> <87v9viuivo.fsf@mouse.gnus.org> <83blx2cr2o.fsf@gnu.org> <8336iecfvr.fsf@gnu.org> 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="89652"; 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: larsi@gnus.org, andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 07 03:02:44 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 1hvALk-000NA7-Ek for ged-emacs-devel@m.gmane.org; Wed, 07 Aug 2019 03:02:44 +0200 Original-Received: from localhost ([::1]:36838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvALi-0000cs-Pe for ged-emacs-devel@m.gmane.org; Tue, 06 Aug 2019 21:02:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39383) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvALe-0000cS-Ca for emacs-devel@gnu.org; Tue, 06 Aug 2019 21:02:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvALd-00054w-GA for emacs-devel@gnu.org; Tue, 06 Aug 2019 21:02:38 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50110) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hvALZ-00053d-NB; Tue, 06 Aug 2019 21:02:33 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4A1F316270E; Tue, 6 Aug 2019 18:02:31 -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 E-WEPDKw6nmu; Tue, 6 Aug 2019 18:02:30 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8AF7D162717; Tue, 6 Aug 2019 18:02:30 -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 1FdI50XPdHal; Tue, 6 Aug 2019 18:02:30 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5461416270E; Tue, 6 Aug 2019 18:02:30 -0700 (PDT) In-Reply-To: <8336iecfvr.fsf@gnu.org> 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:239214 Archived-At: Eli Zaretskii wrote: > Was this inspection done on Emacs' own code, or also outside Emacs? Lars didn't say. I assume he meant Emacs's own code. Although almost all uses of decode-time will be unaffected by the change, there's little doubt that some user code somewhere will break because it (mistakenly) assumes that decode-time's result format will never be extended. If this is a real concern, we can go about the change in some other way. One alternative would be to leave decode-time's API unchanged from Emacs 26 and put the new functionality into a new function, say "time-calendrical". While we're at it, we could call the data structure that the new function returns a "calendrical timestamp" instead of a "decoded timestamp", and rename the recently-added functions make-decoded-time, decoded-time-hour, decoded-time-year etc. to make-calendrical-time, calendrical-hour, calendrical-year, etc. This would reduce confusion, as it is harder to remember what a "decoded time" is than to remember what a "calendrical time" is, at least for me. Also, we could document that the calendrical data structure may change in future versions, and that programs should use the new functions rather than inspect the raw data structure. Using the word "calendrical" in the new names would help avoid confusion with existing functions, which don't use that word in their names.