From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 GAXuITZRymMi2QAAbAwnHQ (envelope-from ) for ; Fri, 20 Jan 2023 09:30:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id EMr+ITZRymOW4gAA9RJhRA (envelope-from ) for ; Fri, 20 Jan 2023 09:30:46 +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 1C7743D400 for ; Fri, 20 Jan 2023 09:30:46 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pImmc-0007d3-RI; Fri, 20 Jan 2023 03:29:58 -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 1pImmb-0007bv-ND for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 03:29:57 -0500 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pImmZ-0005sG-VC for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 03:29:57 -0500 Received: by mail-pj1-x1035.google.com with SMTP id m3-20020a17090a414300b00229ef93c5b0so3514405pjg.2 for ; Fri, 20 Jan 2023 00:29:55 -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=e27Tw/48TNGKBBrm+y3PitY7kgYWczbx4lCNU3oIBEo=; b=Z26nsH9vWwoHb3JVHD7ztkTVbzt/ZYc7GcQCIWHvvpbXiEEvS7MVSirLVJ/L4biybl NOX1A7leGP2o5x2tCiMLYk6xSglYH0DkLqGRwdM9nYRQgCKzWYQL4lmdHJ5ZxGDj4pL6 L54OgSMeWm3wj+xkukmxp8Jy7vkfXCxQhNT6lb3dU0g2XO1eAA7AvoLiNSNUueLvwLsE Qu2ApsXvdlhD8qz1WKyx+d6plDQUT0VXB1DIfTN3JTiUvPXBHjcTXjWPaRco/K6Lt2J3 yO+AvZHT6U37ADSspcONwksXXaQkkJFfTagsgFe12IKdaqIV9ZI4QiciS3o1ZIR7A0YB 97Ww== 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=e27Tw/48TNGKBBrm+y3PitY7kgYWczbx4lCNU3oIBEo=; b=gCU1JJnx6AQiZW1j9TY1e/JPHeHS5vWRA8/B9RHKYXRc2N5ACkzkUPS4hGNDKKZbB8 nTOkvFHpQlcxWm4JZsToXw+snzSAZycvdBrqDC+gX8v+b98wo+n+MwsAb00KKV7Vj6QI nlBHKLs4j0jiQNSaedNBJ/Zw5nJVOfRJ3gcsZhE5qr5h1qmEdACw5fWmPxdGsc8Tupgi bwy6xuK/aRVGUqi4co79mDVP/8RSyDtxIDwtqmmSqI7u/TUw0dueXzYn/7qBKCrxbANu NFJ8/R0opLtUYNxgD9qB1r+41uUKGRcpk890uo7RGnkemLQWuX3T31DnTDiBIpdtzJDV 2p7g== X-Gm-Message-State: AFqh2koWB937ZdhDCOB5e15hmDX30NAg26mHJ6CMTd0ifrQirKdyub5z w9J5lx6P3kBPxI+CjMcvCuqXYsPTzJ4= X-Google-Smtp-Source: AMrXdXuGaKsubvi77PD2ZM0gemnBQ74PVxYOYGAzEbqrvZte+kOwfjAw4x9aKf3YcsTOmXVSZbOqQA== X-Received: by 2002:a05:6a20:b925:b0:9d:efbf:8156 with SMTP id fe37-20020a056a20b92500b0009defbf8156mr37679803pzb.31.1674203394057; Fri, 20 Jan 2023 00:29:54 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id q2-20020a63cc42000000b004788780dd8esm22034272pgi.63.2023.01.20.00.29.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jan 2023 00:29:53 -0800 (PST) Message-ID: <63ca5101.630a0220.b2298.3363@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> <87lelxk87a.fsf@tsdye.online> User-agent: mu4e 1.9.16; emacs 29.0.60 From: Tim Cross To: "Thomas S. Dye" Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Fri, 20 Jan 2023 19:17:14 +1100 In-reply-to: <87lelxk87a.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::1035; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1035.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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674203446; 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=e27Tw/48TNGKBBrm+y3PitY7kgYWczbx4lCNU3oIBEo=; b=jIL1I/fcXmTuBPZyORNON/xWu9eXNAi/sioIlUHl/3aMM1z190+slU3Onc1qewcAI24/Dt 2O7JODOw7GmCkkpbhpA2310jePP6Fgry0V1RFi9PPD3twqYhTzThUANjQVeTu97+vZVZbn 0nN9L8UFRwaXU7y3tPalpXsD2XSjU3Yuys90yfQ4TMt/sqzYCVnYYgrIKmjVlH4eTFY+tj 4+QGC2QCTb4vxLxQtuUfxKvcTHTimDvfsPf6HkbVhGf6GiIhya24z3nSzG8OwfgyZ/pY2i Ls0Q2o5FnAWWWWrXRLNS7A1jjMatUtuMj55PfiDA7mLj74/lxan0DMi59glBbA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z26nsH9v; 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-Seal: i=1; s=key1; d=yhetil.org; t=1674203446; a=rsa-sha256; cv=none; b=Ec0N3017G705FaqWp1MBhPdhVvZjAr2BIr+ABXyuJyKWKkK4++LqN/UnltJQx8YuNgJCNC jrLxCwdR22r0/LeIvDco+XzlFqH2q9/aNsL30sYlVopz9+neMeGrAdzMszqRMzmtOjXZoX qnoKdpCIkvPqAO3nDf4Oeg+v8Awy/HVPxT1fQzKUUlq7fL4LQ/A9RvlxTwIztDdgQiDPNm F+I95Yhm7w0Aft8ANgnQvWUtEwJPuOk9t5sp7HxQo1NuXSWDtYnOK31jsTrvYnUB9OZ0pq lXOmwmGmwhimxjkDXnWYAUEQfQ5o+XTdopm9PDE2SC9+kCWhXkAbqxqWfZtA1w== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.78 X-Spam-Score: -4.78 X-Migadu-Queue-Id: 1C7743D400 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z26nsH9v; 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-TUID: Tn8CeONfdzFM "Thomas S. Dye" writes: > Aloha Max, > > 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. >> >> 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. >> >> 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 >> >> 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. >> >> 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. > > Or, one can recognize that the meeting is an occurrence that requires absolute time and a > timestamp with UTC. Each participant will resolve UTC to the local time where they happen > to be when the meeting takes place. The user might toggle between UTC and the local time > translation using overlays, like pretty entities. This avoids the problem of negotiating a > timezone caused by forcing an occurrence to be represented as an event relative to a > fictitious space/time. > Exactly. I am really confused by the constant reference to negotiating between participants or finding a shared/agreed time zone etc. That is all totally irrelevant in this use case as outlined. If we were talking about booking meetings or communicating information about booked meetings between participants or a different bit of software which manages sceduling of meetings like one of those many web meeting booking systems, then that would be a different matter. However, that isn't what we are talking about. We are talking about org mode. All I am talking about here is being able to identify two different types of meetings - ones which need to have times adjusted as a result of daylight savings time transitions and ones which don't and what mechanism org could use to distinguish the two. It is that simple. Your occurrence v event terminology provides two different names which may help label the two different use cases. So far, nobody has shown any reason why using UTC to distinguish the case where the times need to be adjusted and local tz when they don't won't work a a mechanism that can be used to allow org to handle things better than it does now.