From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id WK/IIOqVSGZDWgAAe85BDQ:P1 (envelope-from ) for ; Sat, 18 May 2024 13:50:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id WK/IIOqVSGZDWgAAe85BDQ (envelope-from ) for ; Sat, 18 May 2024 13:50:02 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=C4PZwzIo; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1716033002; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ikCvi6NQEFR18E22jMIXeZiMWrZlzXCos1rp8Bh39ZI=; b=lKLasF38kh6QCs+NcjiaRGts5ObztEg7sgKoghsEOugsReDuZDCVJWsHas4vMawl4UK3U1 pPZ5oY4N0G/VUT/uUvSgKC2PjU7L1t4GevnlzFPPyJddiYl3rJtJTm1YSWMXlFrwI8Lwjw KgYFIzMTdhl+5zNgMrs/2pRuwe6DPPQNj3umngqbuRUJvCSLaT2aYTC76Zv+1uq/F7SWe/ X5QRq5i4M0VHQg5jMCnuCcqHDzjZnv0TyJBpXESZ4Kx5MOtD2FkWQbDw7e5vt3zaiHxDdh ygiGm/Dk83Ho/w1v30PS94ZdqME461/WMd1fT4jLx8FezQjNQsZV5Cpll8zzeQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1716033002; a=rsa-sha256; cv=none; b=Xmt9Tql41wUrWYt7Z7d9WXcMPc8ok3ySvdMi+tD0lO+BZFWZxg8ZstmReUNqq8DAVIvoOt dBFcndWAunK5z/AY2advW9BzunyYWSuTa54jEcjxaGMJpaF9bWMaBbfwC4hXXkrL9Tgf2Y 0gaSREsxf/FRNfonXgfPIcfs7HksOturcw35Dxc5+A2YKj67E0dc4foog8yqR/mTO5H6Mz J3HVbekpMKVGKetGGCL9FUDNMXelgJx8kPRH33d0ywqg3TMqqeT4s8X/ymClA5FAOtMMah zCXvq2MWByBjCBRE5fbGiAPhXUAqxrhp9U7rCbvBQRUGQz1rGeoyqrLwTJ/kUA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=C4PZwzIo; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 40E2A626AB for ; Sat, 18 May 2024 13:50:01 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s8IYq-0000q6-Lq; Sat, 18 May 2024 07:49:12 -0400 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 1s8IYk-0000l2-DG for emacs-orgmode@gnu.org; Sat, 18 May 2024 07:49:06 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s8IYf-0005pf-Qi for emacs-orgmode@gnu.org; Sat, 18 May 2024 07:49:06 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E2FA6240028 for ; Sat, 18 May 2024 13:48:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1716032937; bh=DLcb4Xny1mnD2+qchZHRi9Em5bPG1HB9txnDBofdQgk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=C4PZwzIoHvlNSpfSp0sJ5GWXzJVW8+kA3W3UNzre6wYw618Y86m5ZMZn7BGjmCi9f Za4vl1+iGrEv7cmfzsD+UTJzVVoUebFzgktdt9SJsucJn+UqqXpahfz95yvN5r5maz ORNBIOl/BA3IBCV+WSJL6GEVA+oN//iSFNZgSdH6fUhJCPAwi9L40BhBZarl8JU1/B pGceVsTco3Q+rUcesFiYlB0r8BGWCVuIO9P0R09zVL2/H2CQfLkunoiLfOB+x6wgHB WN571EqzhIVA+RPldV307SziEH8RhpbGa+m8q9PouRxnIvbUC0VRhC3GX7o6Nxs6Nx +Y+tOJHgFkqEw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VhMYP3T26z9rxB; Sat, 18 May 2024 13:48:57 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [POLL] Dealing with +1m/y repeaters when jumping to impossible date (should 05-31 +1m be 07-01 or 06-30?) In-Reply-To: References: <87frvzodze.fsf@localhost> <87v83if2io.fsf@localhost> <87seykpn58.fsf@localhost> Date: Sat, 18 May 2024 11:50:38 +0000 Message-ID: <87a5kntk35.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.58 X-Spam-Score: -6.58 X-Migadu-Queue-Id: 40E2A626AB X-Migadu-Scanner: mx11.migadu.com X-TUID: QIdAZWCFPKuh Max Nikulin writes: >>> On 13/05/2024 17:07, Ihor Radchenko wrote: >>>> >>>> <2025-01-31 Fri +1m> >>>> <2025-02-28 Fri +1m> >>>> <2025-03-28 Fri +1m> >>> >>> Instead of using timestamp obtained on previous step, use original >>> timestamp and multiple of the interval. >> >> This is not possible because of how `org-auto-repeat-maybe' is designed. > > Then the only way to get reasonable results is to store in :PROPERTIES: > either original date (and iteration count) or current date before > clamping (2025-02-31) As Stefan pointed, even this is not a panacea - 2025-02-28 starting date is simply ambiguous because it may either mean "last day of each month" or "28th of each month". Now, I am having second thoughts about how useful the customization I proposed is - it looks like it is only changing one kind of unexpected behavior with another. I still want to work towards applying my patch for the purposes of making agenda calculations for the repeater consistent with reality (without the patch, `org-closest-date' and `org-timestamp-change' yield different results because the former moves multiple repeater intervals forward without considering date jumps), but I think that the customization should be simply dropped. >>> Have you considered using `min' with result of `date-days-in-month' here >>> (or its sibling from timezone.el)? >> >> Not sure if it is going to be simpler. > > My idea was to avoid the backward `while' loop in the code below this line. That while loop is going to have 3 iterations at worst. So, I do not see much benefit trading performance for complexity. >> Although, forcing DST nil will not always help here > > It is fragile, I would not rely on ignoring offset when DST is > specified. Actually you pass mutually inconsistent values, so it is > either undefined behavior or close to it. Yeah. I think that the easiest approach will be converting to UTC first, making the shift, and then converting back to the original timezone. That way, we will avoid issues with moving across DST transition. Also, special handling may be necessary for timestamps without time - currently they are simply treated as 0:00 time, but it may backfire as in my case with DST transition moving the date one day back. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at