From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Lawrence Newsgroups: gmane.emacs.devel Subject: Re: Making decoded-times and calendar dates compatible? Date: Thu, 12 Dec 2024 17:09:44 +0100 Message-ID: <8734isrign.fsf@ohm.mail-host-address-is-not-set> References: <87seqy5qr8.fsf@ohm.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 17:11:13 2024 Return-path: Envelope-to: ged-emacs-devel@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 1tLlmQ-0000CG-Nb for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 17:11:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLllR-0004op-Oo; Thu, 12 Dec 2024 11:10:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLllG-0004jg-59 for emacs-devel@gnu.org; Thu, 12 Dec 2024 11:09:59 -0500 Original-Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLllD-0003iP-1j; Thu, 12 Dec 2024 11:09:57 -0500 Original-Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id DE54711401BD; Thu, 12 Dec 2024 11:09:51 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Thu, 12 Dec 2024 11:09:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= recursewithless.net; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1734019791; x=1734106191; bh=1iis5BCr3BOeZ+KQ+D003YQGxPz2tXgXTUmAwKcVoE0=; b= OJkYrduL1GazmggIOoX39B4y6kL/wV/n8PR7sU83HQcVNTwcD1yjXkBctVu8cp3/ RrS+Lt99vU3/hknoL3xlwsky4rS9vhxR/wv9Na6VuIgT6a7dnprqpbdv/RNya7aD ONuKyvzkH83MwgVXVoa9w3CVR/KjiA1ALLyZLwpCaI0S+yrHH47VQBQ+t9Qi40VI vsIWonTHj8QYa3/J6IlGkP47+2CfhezDnj+K0AT3AHcYFpQ+J1RvlXP+REfkN9lK uEgjCD+aSnv3QTXbLkYbAtnDqvlQGeL8AWuniN109RQlUcXnbsYc8ryQMwztAw+N cM/B8nGOGivQpS2rwPNAEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1734019791; x=1734106191; bh=1iis5BCr3BOeZ+KQ+D003YQGxPz2tXgXTUm AwKcVoE0=; b=aj07q/Xl8d2HijgDZZ/ZGHgW9Kk0gRuce2x+HawE7+5ISulPuoe sIC9KfP3WbaBsb75p/usFeWuYKdlmCdcUexDN2Bgd9SdMz19XBhs5HK2v/c1VQT7 aLBmryRxH5jdolGTriBdLzLHsF2OEedrMa5A4Ikauku48a6QGGwfjeJ8EADDvhRF eL9mx8OaHREnhUf+F0Ivoi1M4W1guCXmQO9KQOBHRh8rgk2oj9uRrsPwZA90WS/w TelbVoYvCYPgUMFESxVmluaMQ/+/CsU/T2aid2eDj2cz+hvZToQpJqHDFHVCeNCU eXDPpx12qd2bm8M5B83FXcG2yyPstptXDGg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkeehgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvvefujg hffffkgggtsehttdertddttddtnecuhfhrohhmpeftihgthhgrrhguucfnrgifrhgvnhgt vgcuoehrfihlsehrvggtuhhrshgvfihithhhlhgvshhsrdhnvghtqeenucggtffrrghtth gvrhhnpeefueffvdeffeeftdeutdfgjeettdduveduudefjedtkeejgfehhedvgffgffdu hfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrfi hlsehrvggtuhhrshgvfihithhhlhgvshhsrdhnvghtpdhnsggprhgtphhtthhopedvpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopehrmhhssehgnhhurdhorhhgpdhrtghpth htohepvghmrggtshdquggvvhgvlhesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: if7394488:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Dec 2024 11:09:50 -0500 (EST) In-Reply-To: Received-SPF: pass client-ip=103.168.172.152; envelope-from=rwl@recursewithless.net; helo=fhigh-a1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326430 Archived-At: Hi Richard and all, Richard Stallman writes: > I tried reading the code of calendar.el to see what data structures it > uses, but I could not find documentation for that. (The file is > enormous.) > > Can you tell me where to find that documentation? Perhaps > wuotq a few lines so I can search for them. The only documentation I'm aware of (besides the Calendar/Diary section in the Emacs manual, which doesn't deal with the programming interface) is in the docstrings of the library. The docstrings of the functions calendar-extract-year calendar-extract-month calendar-extract-day are where the (MONTH DAY YEAR) format is mentioned. I *believe* these functions are used pretty consistently as accessors in the calendar code, so in theory changing the representation would only require changing these functions, but honestly I have no idea at this point how much of a pain it would be. This is the "standard", Gregorian format for calendar dates, but it is not the only format that the calendar works with. Internally it also uses an "absolute" format which is an integer number of days since December 31, 1BC (see e.g. `calendar-absolute-from-gregorian'), and converts between different calendar scales by converting to and from the absolute format (see e.g. `calendar-iso-from-absolute'). Similarly, the only documentation I'm aware of for the decoded-time format is in the docstrings of the functions `decode-time' and `parse-time-string', and in the symbol documentation for `decoded-time', which is declared as a cl-struct with :type list in simple.el. According to a comment there, the point of this declaration is to provide accessors for the various slots in the list, e.g. `decoded-time-month'. > > If we changed them to use a format like, say, > > (YEAR MONTH DAY) > > and > > (YEAR MONTH DAY DOW HOUR MINUTE SECOND DST TZ) > > respectively, changing the relevant accessors, then calendar arithmetic > > functions could also work effortlessly with [the date part of] decoded > > times, > > In principle it sounds like a good idea, but I think that the > incompatibility might be a big pain to fix. Doesn't some user code > have to operate on those formats? It could very well be a big pain to fix. I'm not sure how much user code has to work with these formats. I know I've written some code to work with them once or twice. Personally, I think it's reasonable to change the underlying format as long as the documented accessors (calendar-extract-*, decoded-time-*) continue to work as expected. User code which uses these functions will then continue to work. User code which instead makes assumptions about the underlying format is not respecting an abstraction boundary, and it's reasonable to break this code. But I realize that my personal view may be more liberal than the general view of the Emacs community on this point; that's fine (and I'm surely grateful for it in other cases!). > I wonder also if calendar.el was designed to be compatible with > something in Unix that existed before GNU Emacs. But I wasn't the > one who wrote it, so I wouldn't know. I don't know either. > One possible way to make the incompatible change less of a pain to > cope with would be to use a list like > > (calendar YEAR MONTH DAY) > > in caledar.el. The presence of the synbol `calendar' would say "this > date uses the new format", thus avoiding ambiguity of the datum. > There would still need to be a lot of change, but at least it would be > easier to be sure you found all the places that had to be changed. If we were going to do that, it might make sense to just declare calendar dates as cl-structs, since this provides the tag automatically, and comes along with some other benefits. Best, Richard