From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id IAdJHJBgxmNxDgEAbAwnHQ (envelope-from ) for ; Tue, 17 Jan 2023 09:47:12 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id oC8jHJBgxmM0dQAAauVa8A (envelope-from ) for ; Tue, 17 Jan 2023 09:47:12 +0100 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 08F8B1024B for ; Tue, 17 Jan 2023 09:47:10 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHhc7-0002AC-U1; Tue, 17 Jan 2023 03:46:43 -0500 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 1pHhbx-00029n-0l for emacs-orgmode@gnu.org; Tue, 17 Jan 2023 03:46:29 -0500 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHhbt-0007Eh-Lv for emacs-orgmode@gnu.org; Tue, 17 Jan 2023 03:46:28 -0500 Received: by mail-pj1-x102a.google.com with SMTP id b10so156509pjo.1 for ; Tue, 17 Jan 2023 00:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:from:to:cc:subject:date:message-id:reply-to; bh=al+VuqWnE3cnp/qlQHq0C0DotxaPF3cNmdpDWsXFv9o=; b=jj1TLiRFykbQ3gFmN6EdHRtPF6vULKh+Q/RZuXnz1ds44ldHJMELjy6oZsLgtUlMJ3 fyOumAoIgu83GX6KK7ns1JJdKxT9CGfpgD0gn3l/AJg0kW7LP9AEQAi4dzqkjbJ8x1AZ WToqxNBhurUG5EgrclnXLbUM+8xklLKKdLXnqzkMnMaU+aHFZ7QVvjidj2xOf6Im0BDI /FiWpeIpGw3vtv1ZI3puHOXkDvXSmBHr65qhyOeex9YOs63+msZgTlCN1A/bNlchUe1/ 87CjFeDxtSJfr1HqwR5T8Bj+tJSmSpuuna9EalwzK3ZrD9KYRyEiD+tQXOIvl3yzuJws 8hgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=al+VuqWnE3cnp/qlQHq0C0DotxaPF3cNmdpDWsXFv9o=; b=xI9kTlBwFy02VcG0U+gvRCDRh7i1P+M/o9hmpQ8ZV5Lk1d+bnE86otlNuKH8qAOV+T SY3J/IYobd+VvmMPngJjmpEZ4Uq3lILjTVDKoRYTr4dkS/6Io53YAF9bG8y3o7x1wJrT Ff1sUNPnzaCqpMpJlB563hCsBgL0s0O9u2qblfdNTYtvY309agSRwPjPKW3nqogFSDS1 MOjGHNGzJkiwgIA2wn7Z3SyvtXKyIS4wcMOEOQqR6v/N6mSuaCYEW4pfm22ezWcBMhc6 CsZom7LPjrlAhXQN6eSo6QQz1/0I+eXUvRM8SzD+MmmWakYL32q88NOGMSxNgtSXjql2 M9sQ== X-Gm-Message-State: AFqh2kr82oZ8fhcjH6Trb7L8fg95zioV//WlkUsGJIo/7b2RpdcYm8VZ 7kTO6mzqYbjiUvRHn48TpOyAOVZZaQg= X-Google-Smtp-Source: AMrXdXtEjAeRILM3Q1GNiJLbuGzkcgUEeUeLz/pmOpCuCcpLtsTmoZ8dWpehuiYX6WmYxtVRzt82IQ== X-Received: by 2002:a05:6a20:d045:b0:b8:4b9c:c7c0 with SMTP id hv5-20020a056a20d04500b000b84b9cc7c0mr2220034pzb.54.1673945160502; Tue, 17 Jan 2023 00:46:00 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id y13-20020a63e24d000000b00478eb777d18sm17071612pgj.72.2023.01.17.00.45.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 00:46:00 -0800 (PST) Message-ID: <63c66048.630a0220.427bf.a5f6@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> <63c2aa9e.170a0220.3bb49.9ef4@mx.google.com> <87pmbhz1x6.fsf@localhost> <87wn5mlo7f.fsf@localhost> <87pmbelnd0.fsf@localhost> <87fscajo2q.fsf@localhost> <87cz7ejmgu.fsf@localhost> User-agent: mu4e 1.9.14; emacs 29.0.60 From: Tim Cross To: Daryl Manning Cc: rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Tue, 17 Jan 2023 19:22:40 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, 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.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 ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673945232; a=rsa-sha256; cv=none; b=HSteNSwIf4mq1b83YXudYATcKa++FuQr2uzx+GPbbW4O8cGc3Nr8UUg6s/EpYREuPxcWWC V7A5ocQsSP4UVQslvAbrBZbI/lWKedxqbKO9oMxTY5z4NZIz9q6stp/CqOVUNNov7gBG2o 16PwOo5EfnthBimu69N0CT9r6B3+vyGy51/UIojY44AdpnvjNC1+V4dmFV4DCS/BOZXM+s 6KtrFk1zA32utL92b8pmCWXrA2dI/jDpo5vprfMF0BQAM+xtk8OixXWKhLaFNNwLSRvkFh 9ZE45W12gfrGpIHEHF0DRyn8t7vieIbuiwPj2YjuuSsnwvqbxzwbigncFnw+AA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jj1TLiRF; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673945232; 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=al+VuqWnE3cnp/qlQHq0C0DotxaPF3cNmdpDWsXFv9o=; b=MPrgrSX9Ajzz7sMwx3IzXuiVIOdWp/zXsq8Hl9/ToG1ngrf7vqrTFd3pPYStwFkyyKPK4V 1pL1LiyFS4EjCeamS02jTWAZBKTRv6E+0mPWb8iRt/PZTyROCg43jMYesIa/WJuwRzXZJK dRFpcqoQYS7HWA0P1XpnEsasFo007+rs1Or0WvBVhRhAHPm2VGYJqaJRBjxKmSxGMvx4ag XLlHNHqDJWHg0g5LMarUo+5VRz+57DZ85Hcz4yT0jjxjWgfpVvYiDD0eHPjIYD1y51pOpx Dj7s5Bh8mE+C85ZVOgQjFDjSaen5fFw0JlLAM9DMMIUI4LdTKQ33pKpkYQTduQ== X-Migadu-Spam-Score: -6.29 X-Spam-Score: -6.29 X-Migadu-Queue-Id: 08F8B1024B X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jj1TLiRF; 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"; dmarc=pass (policy=none) header.from=gmail.com X-TUID: SC0SnIfi2fRE Daryl Manning writes: > I'd argue that setting a specific datestamp and time for DST would mean that you expected to meet at that > specific time and date as per DST. If the clocks changed you'd be out of luck (that's where I'd argue you'd > use a non-specified timezone for a meeting that re-occurs at 10:05 regardless of say PDT or PST). > > But if this was an issue with a recurring meeting, then when the clocks changed someone would be out an > hour because they had specifically booked with DST in mind (note: this is more useful than you think - > being in non-DST countries and having scheduled meetings in DST based countries, a lot of cal applications > get this wrong when what I actually want is for that DST scheduled meeting to now be reflected in my > calendar on the fact they've switched to ST in their time zone - so shifted an hour.). > > But I feel this is something that would be for people who need to take advantage of this. And, more often > than not, is a recurring meeting issue when DST/ST changes occur. > Yes, this is one of the areas where there are some subtle issues to work through. With regards to just meetings, I see 3 common scenarios 1. Meeting wiht all participants in the same time zone. The time (lets say 3pm) should not change when daylight savings comes in or goes out. The meeting is always at 3pm even though that 3pm might be different when considered against UTC time. 2. A meeting where some participants are in different time zones to the org user. Here it isn't clear exactly what should happen when there is a daylight savings transition in the org user's time zone. Should the org user's meeting time change or should the participants in the other time zones update their time for the meeting. On one hand, it makes sense that the local org user change the meeting time for themselves either forward/back an hour because it is their time zone which has changed. However, if the meting has a majority of participants in the same time zone as the org user, perhaps those in the other time zones should adjust. Point is, it isn't obvious and there isn't a 'right solution'. Both needs to be supported and probably need to have some way to indicate which is the preferred behaviour. 3. An org user who travels and is often in a different time zone from their 'home' time zone. IN this scenario, they probably want their meeting times to be adjusted to the local time zone they are in (unless they are already recorded in that time zone). Note that this was a specific example form a previous feature request for time zone support in org time stamps. This is just wiht respect to timestamps used for meetings. There are other scenarios with other subtle issues. For example, someone already mentioned a scenario where org is being used to record details about experiments. In this situation, the amount of 'real' time passed between two timestamps is possibly the most important factor. The fact daylight savings time transitions have occured are likely irrelevant - just important any calculations relating to duration are accurate and not thrown out by one hour due to the wall clock moving forward/abck an hour. So far, it seems clear that the solution needs to be flexible and support timestamps without time zone information, with fully qualified time zone specification, with time zone abbreviated names and with time zone offsets. It also seems that the solution will need some mechanism (possibly on a per time stamp basis) for the user to specify what should happen when either the time zone has a daylight savings transition, when the timezone rules change or when the user's 'default' time zone changes because they have changed locations.