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: Making decoded-times and calendar dates compatible? Date: Sun, 08 Dec 2024 13:00:11 +0100 Message-ID: <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="14357"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 08 13:01:50 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 1tKFyv-0003Ww-6D for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Dec 2024 13:01:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKFxu-0004GE-CA; Sun, 08 Dec 2024 07:00:46 -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 1tKFxf-0004Bp-FQ for emacs-devel@gnu.org; Sun, 08 Dec 2024 07:00:32 -0500 Original-Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKFxZ-0002oC-Cr for emacs-devel@gnu.org; Sun, 08 Dec 2024 07:00:29 -0500 Original-Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 1AF2C114011C for ; Sun, 8 Dec 2024 07:00:20 -0500 (EST) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Sun, 08 Dec 2024 07:00:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= recursewithless.net; h=cc:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to; s=fm3; t=1733659219; x=1733745619; bh=pFKSe7uk9L hFH/WGJnz8x0hIUVhMBqBGB+BIIi81ztE=; b=mncBdSq6dU70Xr3d6Q38fs4Ftl 8+4i3KtHa3GBXb8j7lK0iEeNM35bieYfEB1Dfi+rhQ3BYBcAGgZPBOc60Rhdg72C jTUQ87e1KfcRRI1rDPASF04+aGa6MnvxzjO7c8aBVnYRiNxv7GrYxQ8B2j5eVeLE EBVgVd7bJpadguggRmMgB6nXRHuW6LiM0p9NyQN33G26ntsHoMLaZEuE31rCW3zI AqZKZEyKcZz1qQSlkcNtzFvij8L0Z6f88GMrQ/rMK+E8a+7fxzQajyWEeLpz+yv6 BfwraM+++lR0baJLn59TS5rR77c2b3Pvps/bzJwnr0viVHDPxwyBxRzUfr5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1733659219; x= 1733745619; bh=pFKSe7uk9LhFH/WGJnz8x0hIUVhMBqBGB+BIIi81ztE=; b=0 puvDX+m8eTXr9Q1d3qS7qGvObCK1zBxeY5mEX4uStuG3v3UJ5c78lexfeTaPRYk5 mVWXdT8o70s1SGIkde4tVhTEQ110zHIIiTFnH72KfQnS4FFwaFZsitm67/XvNcjv rZ5psMrQyE4K+g1MhQ6jVbF5RbyyjWAUqk7rIaffyIW/bslfequO8X5G10Xez+cx gbRCJBnLyh+lZlLMzOqXdzUTtmNVqnW+AjvHuhzF5RPD5yLMiiRwu/7twqQhDbE0 4pLu7t6qtYvkZ09aCpWKVZYHKSh+HPpYzt4tXH/h4lrZ7H9QByGnyNuEynp0KvvW QSoueK7FawAQDnrDb5ERg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrjeefgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkf ggtgesthdtredttddttdenucfhrhhomheptfhitghhrghrugcunfgrfihrvghntggvuceo rhiflhesrhgvtghurhhsvgifihhthhhlvghsshdrnhgvtheqnecuggftrfgrthhtvghrnh ephfdtieffieevkeetvdetueeuieekvdejgeehffetteffhfdvvefhvddufeejvdeinecu ffhomhgrihhnpegvlhdrihgupdhgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhiflhesrhgvtghurhhsvgifihhthhhlvghs shdrnhgvthdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepvghmrggtshdquggvvhgvlhesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: if7394488:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 8 Dec 2024 07:00:18 -0500 (EST) Received-SPF: pass client-ip=202.12.124.148; envelope-from=rwl@recursewithless.net; helo=fout-b5-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:326188 Archived-At: Hi everyone, I've been drafting a sub-library to handle iCalendar recurrence rules over the last week, and have run into an issue that I would like some feedback here on: the representations used by make-decoded-time and related functions are not compatible with those of calendar.el. I'd like to know if there's any appetite for making these representations compatible in Emacs, so that functions like e.g. calendar-day-of-week, calendar-nth-named-day, calendar-date-equal, and so on could also work with decoded times. The reason this would be nice: handling recurrence rules requires doing a lot of calendar arithmetic. Decoded times have one important arithmetic function (decoded-time-add) but many more useful arithmetic functions, like the ones named above, are part of calendar.el. Most of the iCalendar properties that accept date-time values also accept plain calendar dates, so I've had to write a lot of boilerplate/wrapper code to convert between the two types when necessary, and to do type-based dispatch on values which can be of either type. Both calendar.el and decoded-time functions represent date(-time) values as lists. But the calendar assumes dates are in the format (MONTH DAY YEAR), whereas decoded times have the format (SEC MIN HOUR DAY MON YEAR DOW DST TZ); the month, day and year are at different indices in these lists. 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, which would really simplify working with both types of values from other code (including mine, but I assume also in Org, Gnus, diary, third-party packages, ...). I see that there was a discussion a few years ago about changing the representation of decoded-time values, though, and it seems that there wasn't much appetite even for that because of the possibility of breaking user code which makes assumptions about the underlying representation; discussion starts here: https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00129.html So I expect there won't be much appetite for this proposal either, but I thought I would ask, because (IMHO) the benefits of the change might be worth it. Best, Richard