From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id qAdJIGdfQ2anDAEAqHPOHw:P1 (envelope-from ) for ; Tue, 14 May 2024 14:56:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id qAdJIGdfQ2anDAEAqHPOHw (envelope-from ) for ; Tue, 14 May 2024 14:56:07 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=lkWDPyy3; 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-Seal: i=1; s=key1; d=yhetil.org; t=1715691367; a=rsa-sha256; cv=none; b=E4R0Ll3EKHNDbjH0hDZvVrnMfBmpHOSgdiLoNJtZU8CsDS7t86G3+OcZugkGN+fDu1s5yI giO2W24ikyQDe3lBp1vrtjnnd/P5998KZZUIju1dp4Y73UyDpjuC+5ij8/P3EvgAhptxyP OWTRiKhN9Ol6ooGI3/x9Mqo3/X0dJ1r/iSWqLhYX/hoL13e7SncsAv2iuuj7BjLranUVgZ NMfgZj/9Z2PWTBRPBjcgNA2TVdCrbcS/EiDvgZNP0sWpSmKsi9x1BOda2aRLVkjWcYIOFc mTKGAF0swX4u901ceUo8s9OAzE+NqCYtbQGgYuBcx7Xqjx6XWp5KTG+ZhxNq7A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=lkWDPyy3; 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=1715691367; 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=awlPJRL2mveNc4OqlXzTJIaL6blIoMa5q0qm3+uLkf4=; b=c1KfLceEVccHvJUwIzEebvWeVdDX9rYAtLyTSFhN9roKTFRYeH/k/zxjkX8xklmMYKlYA/ RrIfGzPJwMGs4uUSLQweEpdlYp8V03maqM/wVheouIXGGCj8JSoOC/mhwOxg7vD25xP/Rw JMuq6K4eC6biZugZ6nkp6woN+/Ws+eDIjANyxu4qjfjkZ2nn7qKBxy//yiwtb9I4D0+nAQ CiazV/aCaqi+BdN55zqfnWx+etdkK1dirvTLBr86DrtVDYdfLhCnyo/ysSMwEWIlSBLry2 jEjPkqDJp+lz9AC+EUBPg+dfXVI/Z0AO+prrtQm0pjvdOxEBoA3aueacDYXiOQ== 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 14B471A274 for ; Tue, 14 May 2024 14:56:07 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s6rgl-00032X-I2; Tue, 14 May 2024 08:55:27 -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 1s6rgi-00032A-46 for emacs-orgmode@gnu.org; Tue, 14 May 2024 08:55:24 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s6rgf-0005dS-Ag for emacs-orgmode@gnu.org; Tue, 14 May 2024 08:55:23 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id DC288240101 for ; Tue, 14 May 2024 14:55:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1715691317; bh=MoU15ozhu2Y3CE4HRBaL5dM0OndZq5SaQ0FMfFFn7kI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=lkWDPyy3ROfUclqT77lBpXWJUxdXo1G2xEgCUuvEUnIzikkzwrYodoYjieM7UiGsX M/d2vr+kHJ3rhw1YHWZUrXG3gNCpjCFyImXZ+ij/YCuqw7wt+3TEFjBc+m1FsZ35xv ULT63U3dm4HCW9YVd09tUfAnxP9LkrKsEKQr+hAm5TRAnKTK8tSKScvDYT+meohBvD yTCS1FrqGR4utWoKTZcSG3+Sp+JBFo2PakTQrj4zIaqDSok86PK45uXxBcn1YC3uF8 IkXAnGR8Ry5mO1NkO0jW9s4HS+fEErD/+eIzFceLaObvIs47YV2sAazRPyKDgGV5LV TVi7/XpdHfWWQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VdxCm5fF1z6tsb; Tue, 14 May 2024 14:55:16 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin , Adam Porter 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> Date: Tue, 14 May 2024 12:56:51 +0000 Message-ID: <87seykpn58.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 14B471A274 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.08 X-Spam-Score: -8.08 X-TUID: V7VWqLGsHV4k Max Nikulin writes: > On 13/05/2024 17:07, Ihor Radchenko wrote: >> >> However, there are still some issues remaining. >> When updating timestamps repeating monthly across months with 30, 31, >> and 28 days we get >> >> <2025-01-31 Fri +1m> >> <2025-02-28 Fri +1m> >> <2025-03-28 Fri +1m> >> ... >> <2026-01-28 Wed +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. When repeater is triggered, the original date in the timestamp is replaced with future date. So, we have no access to the original date in the timestamp. > I have the following in my notes. However I have not find suitable > functions in elisp: > > https://debbugs.gnu.org/54764#10 > Paul Eggert. Sat, 9 Apr 2022 00:52:57 -0700 >> Generally speaking, >> when Org mode is doing calendrical calculations it should use >> calendrical functions rather than encode-time+decode-time, which are >> best used for time calculations not calendar calculations. > > Do you have any idea what Paul was writing about? No idea. I am not aware about any existing built-in API that provides date increments. >> + (org-encode-time >> + (list >> + (+ (if (eq unit 'second) value 0) (decoded-time-second time)) >> + (+ (if (eq unit 'minute) value 0) (decoded-time-minute time)) >> + (+ (if (eq unit 'hour) value 0) (decoded-time-hour time)) >> + (+ (if (eq unit 'day) value 0) (decoded-time-day time)) > > 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. >> +(defun org-time-inc (unit value time) > Is there a chance that support of intervals like 1h20m will be required > later? Not sure again. I simply used ts-inc function signature from Adam's ts.el as reference. >> + (+ (if (eq unit 'month) value 0) (decoded-time-month time)) >> + (+ (if (eq unit 'year) value 0) (decoded-time-year time)) >> + (decoded-time-weekday time) >> + (if (memq unit '(day month year)) >> + nil ; Avoid auto-adjustments of time when jumping across DST. > > Sorry, but you have to use -1, otherwise > > (format-time-string > "%F %T %Z %z" > (encode-time '(0 30 12 15 1 2000 'ignored nil "Africa/Juba")) > "Africa/Juba") > (error "Specified time is not representable") Hmm. I am not sure if it is a real problem in practice. String values of time zone are only possible for hand-crafted time values. Using `decode-time' does not retain the time zone name: (decode-time (encode-time '(0 30 12 15 1 2000 'ignored -1 "Africa/Juba"))) ; => (0 30 12 15 1 2000 6 nil 7200) The reason why I forced DST nil is hysteresis of glibc when dealing with DST transitions: (cl-loop for m in '(1 2 3 4 5 6 7 8 9 10 11 12) collect (decode-time (encode-time `(0 0 0 4 ,m 2012 nil -1 10800)))) (0 0 23 3 1 2012 2 nil 7200) (0 0 23 3 2 2012 5 nil 7200) (0 0 23 3 3 2012 6 nil 7200) (0 0 0 4 4 2012 3 t 10800) (0 0 0 4 5 2012 5 t 10800) (0 0 0 4 6 2012 1 t 10800) (0 0 0 4 7 2012 3 t 10800) (0 0 0 4 8 2012 6 t 10800) (0 0 0 4 9 2012 2 t 10800) (0 0 0 4 10 2012 4 t 10800) (0 0 23 3 11 2012 6 nil 7200) (0 0 23 3 12 2012 1 nil 7200) Although, forcing DST nil will not always help here, so I need some other solution to this problem. (timezones, DSTs... :sigh:) >> + (decoded-time-dst time)) >> + (decoded-time-zone time)))))) >> + (if (not org-repeat-round-time) new-time > I am in doubts if `org-time-inc' should access `org-repeat-round-time' > directly or its value should be passed as an explicit argument. Perhaps > the additional argument may be optional with fallback to > `org-repeat-round-time' when it is omitted. This is of no use for now - we do not need to pass different parameters to `org-time-inc' from the existing Org code. But we can always add an extra optional argument if necessary. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at