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 ms13.migadu.com with LMTPS id +KHjBDzxc2YPxwAAqHPOHw:P1 (envelope-from ) for ; Thu, 20 Jun 2024 09:07:08 +0000 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 +KHjBDzxc2YPxwAAqHPOHw (envelope-from ) for ; Thu, 20 Jun 2024 11:07:08 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ghxXDNU6; 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=1718874428; a=rsa-sha256; cv=none; b=iJg3qvF9+GA07+nO5V8uJH0aeOXllZBgJpdDtzm5fTmpEc5gXoBgaBsmm+L3MXHzDfMnmG d+qZRB+WPeDUIDj6EfJ4daRUSGdjvt5rpfAUnqBF7f1tHZIwLun/bMAHex0q4MEdcSQHaz a1DY0ANJtUTCXE60iEI9lMztZHs08u4l0pSPGiI64OaQnrLAonxosCVq+IbKlbkuFhYk9X /DcokPCecExw9uPN/Ydr1Enjf8uN30larjAfIrXLmzvRsYU1HhhAJs18tZ13JzUGKKqbyj jhFDaGIhhpGn3VEaUgq7+HyMj1SgXrzkqhR4EIJNmP3LeXDYK4wbMK8qzNRh2w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ghxXDNU6; 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=1718874428; 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=I14IY/Kp/sHcjxoMgaoQH3CMH+7d7PVjuNtytU4E3RU=; b=srbEYeroPZN27dRDE3sMzdQ0NSm2skmWWgsJhZ9imt0AwLd/JX2FuVCOnJF4vzwiiBU7fI 6p4PtNLfwzNxeMjeLhziq6BlKHBWVygw8UVSXgWah2r1ufEodKfFo/tN65liMusZneXiti 7dtk7LhE+seN5nIyDNXhEh7LIz65T3X0SsmkdH0y/6VjaqKpwxW+EbwONxCe9wu033mv/Y RNrS4/M4KO9YoJ9oX0Gnk6bZcIFTcILzdMpqGUrHWc0/E6WnwZ+6FFI3rd9EaWnsP1+KOx v6+r9u0iPRWilw3VgydQfflBN1E7AqgMn9hTdErWk/WHbY4lXY/1zjP6TeedEw== 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 B92B761AE9 for ; Thu, 20 Jun 2024 11:07:07 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKDk7-0006LH-D5; Thu, 20 Jun 2024 05:06:07 -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 1sKDk5-0006Kk-Ba for emacs-orgmode@gnu.org; Thu, 20 Jun 2024 05:06:05 -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 1sKDk1-0003xF-PW for emacs-orgmode@gnu.org; Thu, 20 Jun 2024 05:06:05 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 83673240103 for ; Thu, 20 Jun 2024 11:05:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718874358; bh=ui7MyYuBLT3XrkmdOL7FPflMYoxxRqx6c0Pk9Lu8y+Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=ghxXDNU6QP7mkwSiljAZztlMmvyoGKv5+5TtgJoCuefJ2JG2yh9dHS4l6DYJ2kMdb GbSa6VPiVJGYQzkZiOpAu8a4BYbe5D8RL8ZV7h2LQvkccKS9o8OQRxtu5aa7CDfcPY CDE++w/vyDRU507340djBP968eHCHK9q1c5/XjiNQ7iZYHLqziydwgGKtAGNa1a4SS RtTC16DMEl/MD30lge7g33WxAm4UlBH1OBXmmZ2HmNAO3T0KzUacwaIFS7UvKKWw7k LgPcCYaSrAqfDzUk0xZVuGI9YITlIZwgZI1qVyVySyfekTynFHUL4T99LPrNCx/Y2U xl9YZch41fSKQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W4ZN44s01z6tmv; Thu, 20 Jun 2024 11:05:56 +0200 (CEST) From: Ihor Radchenko To: Morgan Smith Cc: emacs-orgmode@gnu.org, Sanel Zukan Subject: Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx In-Reply-To: References: <87r0f9b9n2.fsf@localhost> <87frvpyzrf.fsf@localhost> <875xu6aee8.fsf@localhost> <87bk3x9bpv.fsf@localhost> Date: Thu, 20 Jun 2024 09:07:41 +0000 Message-ID: <87h6do7zj6.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, T_SCC_BODY_TEXT_LINE=-0.01 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: -9.58 X-Migadu-Scanner: mx12.migadu.com X-Spam-Score: -9.58 X-Migadu-Queue-Id: B92B761AE9 X-TUID: aeT+4fo9D46s Morgan Smith writes: >> That's expected. >> We have the following _syntax_ description for clock lines: >> >> https://orgmode.org/worg/org-syntax.html#Clocks... >> clock: INACTIVE-TIMESTAMP-RANGE DURATION > ... > My specific issue is that the ":*-end" stuff can be set when the > "*-start" stuff is not. > ... > CLOCK: [2023-11-15 Wed 15rr:26]--[2023-11-15 Wed 16:12] => 0:46 > calculated time: 58320.0 > ... > What this shows is that an invalid end will cause the entry to be > ignored, but an invalid start will not. Yup. Everything makes sense, but only within syntax spec. Actual code that handles such clock lines is another story. > We can totally claim that this is a feature, not a bug, if you would > like. As this essentially treats > "CLOCK: [2023-11-15 Wed 15rr:26]--[2023-11-15 Wed 16:12] => 0:46" > as > "CLOCK: [2023-11-15 Wed]--[2023-11-15 Wed 16:12] => 16:12" I consider this as a problem that should be addressed in `org-clock-sum' - if opening/closing time is not specified, there is likely some typo in clock lines. So, as you saw in fd8ddf2874ca00505aa096c6172ea750cd5e9eaa, I want to display a warning if something is sus, so that the user is notified that time calculations might be off. Warning is important because a number of people use clock functionality for billing - miscalculating clock sums can literally affect people's income :) I think that the best course of action when a problematic timestamp without opening/closing time is encountered is: 1. Warn user 2. Still calculate the duration, assuming 0s in time (simply because previous versions of Org mode did it) (2) is kind of debatable, but I can imagine some users might make use of such feature by putting clocks by hand: CLOCK: [2023-11-15 Wed]--[2023-11-16 Thu] => 24:00 These users may then simply suppress the warning. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at