From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +IJ6BU7ZIV9KPgAA0tVLHw (envelope-from ) for ; Wed, 29 Jul 2020 20:17:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 8AhvAU7ZIV+qCwAAB5/wlQ (envelope-from ) for ; Wed, 29 Jul 2020 20:17:18 +0000 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 7D34C940653 for ; Wed, 29 Jul 2020 20:17:17 +0000 (UTC) Received: from localhost ([::1]:50832 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k0sVm-0003l8-Vd for larch@yhetil.org; Wed, 29 Jul 2020 16:17:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0sVR-0003l1-8V for emacs-orgmode@gnu.org; Wed, 29 Jul 2020 16:16:53 -0400 Received: from www.selma.hfmdk-frankfurt.de ([46.4.92.145]:41378 helo=mail.selma.hfmdk-frankfurt.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k0sVO-00024f-4Q for emacs-orgmode@gnu.org; Wed, 29 Jul 2020 16:16:51 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id 8AA19F62BDD; Wed, 29 Jul 2020 22:16:41 +0200 (CEST) Received: from t460s-orm.selma.hfmdk-frankfurt.de (ip-95-223-157-3.hsi16.unitymediagroup.de [95.223.157.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mail.selma.hfmdk-frankfurt.de (Postfix) with ESMTPSA id 6F144F60BED for ; Wed, 29 Jul 2020 22:16:39 +0200 (CEST) Received: by t460s-orm.selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 063707340218; Wed, 29 Jul 2020 20:16:34 +0000 (UTC) Date: Wed, 29 Jul 2020 22:16:34 +0200 From: Orm Finnendahl To: emacs-orgmode@gnu.org Subject: custom time format extension Message-ID: <20200729201634.GA813784@t480s-orm.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Disclaimer: Why are you listening to me? X-Operating-System: GNU/Linux Organization: Hochschule =?utf-8?B?ZsO8?= =?utf-8?Q?r?= Musik und Darstellende Kunst Frankfurt, Frankfurt, Germany Received-SPF: pass client-ip=46.4.92.145; envelope-from=orm.finnendahl@selma.hfmdk-frankfurt.de; helo=mail.selma.hfmdk-frankfurt.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/29 16:16:41 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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.23 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" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.91 X-TUID: BONnUwFrTQ24 Hi, when exporting timestamps it always bothered me that timestamps with start and end time on the same day got exported with a full date for the start and end times separated by a dash. After thinking about this for some time I implemented a method today, which combines the advantage of being utmost flexible while maintaining full backwards compatibility. This is how it works: The cdr of org-time-stamp-custom-formats normally contains a format string for formatting timestamps with start/end time. When supplying a list of three strings instead of the single format string to the cdr of org-time-stamp-custom-formats, the first, second and third elements of that list are interpreted as follows: The first element is the full format in case start and end of the timestamp are not on the same day. The second element of the list is the format string for the start time of the timestamp. The third element of the list is a format string for the end time of the timestamp. (BTW: Supplying a list as second element of a dotted list is equivalent to supplying a list with four strings to org-time-stamp-custom-formats) Below the mail is a short example for german date strings. In case somebody is interested, I can provide the code off list. If any of the maintainers is reading on this list and thinks it should get revised and maybe adopted for orgmode, please let me know how to issue pull requests for the code. I tried to be minimally invasive ;-) -- Orm ----------- Example: (org-time-stamp-custom-formats '("%a %d.%m.%Y" . ("%a %d.%m.%Y %H:%M Uhr" "%a %d.%m.%Y %H:%M" "%H:%M Uhr"))) Formatting <2020-11-21 Sa> -> Sa 21.11.2020 <2020-11-21 Sa 10:00-18:00> -> Sa 21.11.2020 10:00--18:00 Uhr <2020-11-21 Sa 10:00>--<2020-11-22 So 18:00> -> Sa 21.11.2020 10:00 Uhr--So 22.11.2020 18:00 Uhr