From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yBGzLGIyymOWqQAAbAwnHQ (envelope-from ) for ; Fri, 20 Jan 2023 07:19:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id MPTCLGIyymOdqAAA9RJhRA (envelope-from ) for ; Fri, 20 Jan 2023 07:19:14 +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 DBF3017B47 for ; Fri, 20 Jan 2023 07:19:13 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIkjH-0005n0-MJ; Fri, 20 Jan 2023 01:18:23 -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 1pIkjG-0005mr-2S for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 01:18:22 -0500 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pIkjE-0004X5-6F for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 01:18:21 -0500 Received: by mail-pl1-x636.google.com with SMTP id c6so4507875pls.4 for ; Thu, 19 Jan 2023 22:18:19 -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=YST/chPpLfTBajyrxehhzTWgVH9KpsFhalgjuiY0LHc=; b=NxJ1tBF+ddP+kiWdnHbzFuTAtqXwcCexm6yIdjPBcSdqBwyP2Hz6wIY1f+YzyKty3e e0iDkvJU6ZB8wdnjEcGofsUkCL/xkMnucY4PMACH3ub6IPRKuheYyNCHUM0TlpB/uxqQ HqbCrslLtpSakI7gBLhJitPsnrqqEZLbWvipcEO5uBllsr7GymZry1TAYukNhapWWPn4 ly7PXXeml0P6BTXpDvokMO6bS0eQtwiPVtrG89GrTzRomVAnI6Zut/j7EiKp4BSdeXu6 8kBZdk9OdB5rtMx+kJBzato4br/xaCCZU6D9hPUdxMdxXeHu0KjX8TPkjSfIB69QmFlc x0kA== 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=YST/chPpLfTBajyrxehhzTWgVH9KpsFhalgjuiY0LHc=; b=FzkzJrejLkcJ9sxRY54Eb6Yqg0/cS9QWf/Nl3V7Ly/xS8Mc539FchpdV31959i76Tb eGrWCoUUERznlU1jGTfAWCRNtHvR7v9jNXYQvyInl65w4/g9nkBqtBmlEjGMGAIlC+PT EUEWfGJgTJ4wq3xWAOEMrBtpv9+qBCeXF9J7dzxUIza506X/OwiH62BmXkcPt5DcHLoq /9PdtsDRI4/O0qlVarV5MhZjdBfnRTrVRhTb0svimiDxWXIre+C4xCeNcg+0BC1w/nmU yOwIQV4Ay+P5sCAr2XP77bzShivbOpp3MsAg6mNFAZmnk6RNO3wpIeoNXn/tmkhyZDpF TR9w== X-Gm-Message-State: AFqh2kpu05ifVSamj2Rg1vl4Sc6CvoWXGQiJ0C7yBfz6ZKa4wONjC1ls S9Cg8Z1pbaRV98/zmClD/tnjgT4RnpY= X-Google-Smtp-Source: AMrXdXtX/x2XR2LGFxiWetI6ZP1ynbiL3rH6zFawLK6ZFagDMCd+p2s2wMmt75lOb9roRnV9bHNOMw== X-Received: by 2002:a17:903:185:b0:194:dd86:587f with SMTP id z5-20020a170903018500b00194dd86587fmr3267790plg.54.1674195498150; Thu, 19 Jan 2023 22:18:18 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id z9-20020a1709027e8900b0019472226769sm13187014pla.251.2023.01.19.22.18.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 22:18:17 -0800 (PST) Message-ID: <63ca3229.170a0220.a0833.5667@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> User-agent: mu4e 1.9.16; emacs 29.0.60 From: Tim Cross To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Fri, 20 Jan 2023 16:39:48 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x636.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=1674195554; a=rsa-sha256; cv=none; b=ljfFxF3YUWXM0i1dU7IH3K/1+dvXLReZovAU9QpBlFCrxQv/43UqoPQCwT6mi2yeKBJQaV YwusXzjMmpWEulTX3Udr4LexqYC8jKmNbr5jb4ACL8O2Myi7qw/uJRab/pDw7xdci2z29+ CZONIqOYuO+BYVXVoYVbleBm/UZaCr4Tj6ne+ypJXzQhV/Kz29gCl2CAiYOnjPpHD5rG1n D+2gPRnVXF2phA35biGvDSpZeLlPTMcxnrCNdkLDiGhlMfaxPiNfNgE5m5AW2hYwhf6C5N 0+T29zYhRqpHdS4H2FO9A/fxadmsOuUNxrc7FW+jN8hrPuLegFhjPWumwzzwsw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NxJ1tBF+; dmarc=pass (policy=none) header.from=gmail.com; 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=1674195554; 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=YST/chPpLfTBajyrxehhzTWgVH9KpsFhalgjuiY0LHc=; b=V0alLpbWV8NmujZGwmrsTHA/JLerJjESdICy89vRYT0Hb07Ja51LVMr55PYwjioEdWrbNz ekT+d++glD4parc4NcIkj/ZA/T/e9s3n78HoAoZEQNDCxs2FLtUnrJTmm6FMDXiJReFoZM myXjfWCe+DkkRDKVp9sviICI+PbwFsaR9Jr/O+rOCm5kdH42AGKKwVeJD+K4ZMUzT/431p +k71RTXBJI5rVSEsiNZG/A3/X0P2ywvNjmZo1n4LrmkPS8qReEathibToQAVkj+e9FMlK6 BUtCSESDMnXk6G88bvz7nZ6zFnAF0ZuP86Su2zVT8R9s2fSrnNR6000zDyfpmw== X-Spam-Score: -6.08 X-Migadu-Queue-Id: DBF3017B47 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=NxJ1tBF+; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -6.08 X-TUID: uIbSzAfxhB8H Max Nikulin writes: > On 20/01/2023 03:09, Tim Cross wrote: >> To reiterate for the last time, there are 2 clear and different use >> cases for timestamps associated with meetings. >> 1. A meeting timestamp for a meeting where all the participants are in >> the same time zone. > ...> 2. A meeting timestamp for a meeting where all the participants are in >> different time zones.... > > Tim, every scheduled meeting event is associated with some particular time zone, often > implicitly. So it is single use case. > No, I disagree with that statement. That is old thinking based when meetings meant face to face meetings. Only meeting which have a specific location can have a time zone and even then, it isn't really the meetings time zone, but instead the time zone of the participants at the meeting. Meetings without a specific location do not have time zones, implicit or otherwise. If you have an on-line meeting with 5 people from 5 different time zones, there is no time zone which takes precedence and cna be thought of as the meeting time zone. You could decide to do that if you wanted, but it doesn't achieve anything useful. > It is up to participants to negotiate which timezone is the primary one for each event. It > is matter of people communication, not technical issue. > The issue I'm talking about has nothing to do with the other participants of the meeting. It is irrelevant to them when my time zone changes due to daylight savings. > First Monday 15:00 is (almost) equally precise for > - Australia/Canberra having DST > - Australia/Darwin where currently no DST > - +1000 (the highest chance of improper use unfortunately) > - UTC > That is a bad example and is wrong. Australia/Canberra and Australia/Darwin are different timezones regardless. Darwin is +930 and Canberra is +1000 (+1100 with DS). So Monday 15;00 in Darwin will be at 15:30 in Canberra outside DS time and 16:30 during DS time. > Aside from time transition intervals, it is possible to take any of this variant and to > present time local for other participant across the globe. > > Storage timezone may differ from the current user preference which time zone should be > used to display timestamp or to export it. > > The problem arises when several participants believe that their timezones are primary ones > and they do not sync their schedules through a shared file or a DB entry. An application > can not solve this problem, but it might try to help to identify it. Some efforts are > necessary from user side. Timestamp should contain list of timezones of other participants > and cached local time. In such case an application may warn users that local time values > become inconsistent due to DST transitions or due to update of time zone database. Unsure > to what degree it should be implemented in Org. > and this is not the issue I'm trying to solve here. At no time did I reference booking meetings or scheduling meetings with others. This has nothing to do with eh use case I was outlining. > So > - It is participants fault if a meeting is not associated with particular timezone > - Having a fair time handling library, it does not matter what time zone is used to > schedule the meeting. OK, I just give up. I don't understand why my very simple point seems so hard for anyone to grasp and why everyone seems so focused on the booking and scheduling of meetings with outhers. This was never in the scope of the very simple issue I want solved. All I want is for org to tell me when my meeting is. I don't care about other people's time zones or when the meeting is for them, I don't care who books the meeting and I don't care whether someone feels the meeting has a time zone or not because it is all totally irrelevant for my use case. This is very very simple and doesn't need to be over thought. I have two reoccurring meetings. Meeting 1. All of the people for this meeting are in my time zone. When daylight savings transitions occur, there is no impact. THis is how org timestamps work now. Nothing is required. Meeting 2. This meeting has 5 participants. They are all in different time zones. When daylight savings time transitions occur in my timezone, I need the time stamp to report an adjusted time based on the change (either forward or back 1 hour). Currently, org cannot manage this and my meeting time is out by one hour for 6 months of the year. How is this handled by org? My suggested solution, which I feel is quite simple is to simply use a timestamp with a UTC or Etc/UTC value for the time zone for meetings with participants from different time zones and where the time of the meeting must remain constant with respect to UTC. Assuming that once org timestamps handling has been updated to display timestamps according to the local time zone, the issue with the second meeting example is solved. Thats it, done. You might sayh this isn't a technical issue, but it can obviously be solved adopting a technical solution. All that remains is to work out a good interface to make it easy to set the correct timestamp type (i.e. in local time or UTC) based on the requirements for that meeting (which is determined by whether the meeting has any participants in different time zones). How sophisticated we want ot make this is undecided. My simple sugestion wa that have the commands which insert timestamps use the universal argument - when called with the universal argument, set the timestamp using UTC and when it isn't, set it as it is now (or set it with the local TZ added, based on user preference).