From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id oCcxDKkq32OqNQEAbAwnHQ (envelope-from ) for ; Sun, 05 Feb 2023 05:03:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KPlBC6kq32PhLAEAG6o9tA (envelope-from ) for ; Sun, 05 Feb 2023 05:03:53 +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 A13A62920C for ; Sun, 5 Feb 2023 05:03:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOVRq-0001WS-5E; Sat, 04 Feb 2023 22:12:10 -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 1pOVRo-0001WC-HX for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 22:12:08 -0500 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOVRm-0002a9-Qn for emacs-orgmode@gnu.org; Sat, 04 Feb 2023 22:12:08 -0500 Received: by mail-pf1-x432.google.com with SMTP id t17so6283225pfj.0 for ; Sat, 04 Feb 2023 19:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=U6HMzt8df5F2Byj3xvYx88PIZObtTAz+8sQzpKTf4/Q=; b=AY8bYj5mCHEb7jLnL3YZvhZ//V6gXy4fD41T4T7ebHkoId8oXhgQUHvuf+posyX1A0 XDkMWszxIDUvFdsFnSM0AraDGn2KhVHyQZ69pBFkgdkqaoK5IPgGnZattBGKdu7ZhAKH /bZmbzohJq57mg7shqiusLjJqb2bEbytgE1YhBUo3WIBnd38h0iqlVIjdUZTKHG9pRya mZBiCreA6O9QtIp6L/6w+fdBkUgBuROTTpxBzv2FdeG3rb6fMzMYRzMI7psPeP/EXL0W 0cxdjV8QrYl9f3xQMTiEe0ynEYXj80YUHNXoP6hQPR+U14kBCBUQvgIi+Q6bTbAc7L1i uOaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U6HMzt8df5F2Byj3xvYx88PIZObtTAz+8sQzpKTf4/Q=; b=LOEM7aVGyMNSco7mjaMqkk5k8Rw83OBh+Yau//9Z1Y37obP3b0NnY/SkopwC4nEGrE GAPqAgshLhWwD3rD3mYS0liVyXcUXzMhZJoFvaMRlPAqiAp1RfOqWlZTeYTuX4Nsectt RNXuXN19vhuHwB7bas+1nct2K3TZsWkKzsCppPtf7SSSq3uddRoT8oX31zCSp7On0tsV T0lOFjakK8iu1VDslebxx+3GdCA2F/o51Lbg04f8t8AbyUOjZfpmTIgBzM1uAlGMOTvJ iaarvuOHPAAltSzhkR7tZuB3mZLVtZcrSU5z2yyyWX/zxXVpSaeh284pH0BeAIhU/SVu haaw== X-Gm-Message-State: AO0yUKXWS+d+Loxw+Sq+7iEJqL3+znUv6xIyPPiDm0eLE45hK7kHaQt8 3b2iXw8yHRnlQJZQi3woQ94= X-Google-Smtp-Source: AK7set/FArvTqNUPR8T+0m1OhtAVnur2b7Le7KmL4OY0E4XDmvGEOoPaNLIjF26NdVv6trLmq1306g== X-Received: by 2002:a62:6413:0:b0:59b:a67:49ca with SMTP id y19-20020a626413000000b0059b0a6749camr2693896pfb.18.1675566724982; Sat, 04 Feb 2023 19:12:04 -0800 (PST) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id e3-20020a62ee03000000b0058e1b55391esm4491635pfi.178.2023.02.04.19.12.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Feb 2023 19:12:04 -0800 (PST) Message-ID: <0db22715-a54e-28af-1ea4-73f974e838b0@gmail.com> Date: Sun, 5 Feb 2023 10:12:01 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Content-Language: en-US To: Ypo , Org-mode References: From: Max Nikulin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=manikulin@gmail.com; helo=mail-pf1-x432.google.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 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, NICE_REPLY_A=-0.09, 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675569833; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=U6HMzt8df5F2Byj3xvYx88PIZObtTAz+8sQzpKTf4/Q=; b=gQrDl1V00Zwa3xNJFXJ/FbgPBjvKwsetkwQCYRgMayOnit5/rM3EVlPzEQ7d+x2SMCf/Xn APG5OKxtzA3nIDAkfPL90z3C3DrBeOQGKs33wt7RtHEe6LwNH7hzwret1enarJzQk/fPnt czdKBxtHNJyxn7m8QMq/Y3kKs+mfkJlKEtUHGZQgiH7W+/iPlgIb8LFIN4XyUW63T2wLDq hRrwL3lxOK1AOKIRSzYyAvdma+ZWiJve7+81ql6Lv2C4wKWJbVMHNsqLidd9Eehqpcqq+2 T4780fCs6eArcJTzhvWhlIgrwXbIblHDxOTyfsnAa0HjB8+m+oclj/qx4tHkoA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=AY8bYj5m; 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=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675569833; a=rsa-sha256; cv=none; b=M/6TvHGpCnMdhIXGjcbux7O3mv6BqgWDj93MmY1TQ78MaX0LazqvnpAU1SrUXw5pjFjU7p oEp0H/I5X96ISKg4XcdSNcuHJ5bjmNsz03FEBCwCAUYGg6KnmpKAD/uPGOOKrkDnKUA+r/ VhW5m8pd2BlwLM/AW//QCqJeErTVbdT/CfFljR4WP29IipmNjgubW4++mM+a7uQE+rGUeN ifKz6MUKG4Ndw+kaAEKzUV4RLo4LcMROP+AS84WzvdTKKyIjr8KEd5m0dtyDphuJiOz1aX 2p2JIfrazOn/OnAePPbt/oxklxwFyQ3AKDVde5M0mWCEB9I8+iGbmqk6mD5iFA== X-Migadu-Spam-Score: -1.79 X-Spam-Score: -1.79 X-Migadu-Queue-Id: A13A62920C Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=AY8bYj5m; 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=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none) X-Migadu-Scanner: scn1.migadu.com X-TUID: ybjPnDBW6Vrc On 05/02/2023 04:38, Ypo wrote: > > If I wanted to assist to a "Mastering Emacs book club" meeting in > America/Vancouver, while living in Spain: Doubt: Should I use local time > of America/Vancouver to schedule the meeting?. Like: [2024-02-04 12:00 > @America/Vancouver] (I don't like space before the @, for the Poll). Below is my vision. Others may have their own opinions concerning particular details. Depending of choice of persons in charge of this event you should add to your .org file either - <2024-02-04 12:00 @America/Vancouver> if convenience of local participants is the most important point - <2024-02-04 Sun 20:00:00 @Z> == <2024-02-04 Sun 12:00:00 @-0800> if enough online participants are expected, so the time is fixed for everybody independently of possible changes of the America/Vancouver time zone. You may add <2024-02-04 do. 21:00>, but it will increase maintenance burden, see below. > 1. Doubt: I suppose my agenda timestamp would be: [2024-02-04 do. > 21:00]. (Spain local time). Correct? Agenda may display timestamps in your current time zone using overlays or just by formatting during generation of agenda. > 2. If I went on vacation to Brasília, my agenda timestamp should change > to: [2024-02-04 do. 17:00]. (Brasília local time). >    Doubt: How must the local time zone be updated to get that timestamp > changed? If you have in your file either <2024-02-04 12:00 @America/Vancouver> or <2024-02-04 Sun 20:00:00 @Z> then you do not need to update anything. You just set your current time zone to proper location in Brazil (and perhaps regenerate agenda) > 3. Back to Spain, I see that, for political reasons, Vancouver's winter > time-zone changed from UTC-8 to UTC-9. >    Doubt: How would my tz database be updated? On Linux tzdata package is updated several times every year, this case you just need to keep your system up to date. >    Doubt: After updating the tz database, my agenda timestamp would > change automatically to  [2024-02-04 do. 22:00]. Correct? If you saved the event as <2024-02-04 do. 21:00> certainly it is up to you to find an update entries (and unsure that no timestamps is updated twice) to <2024-02-04 do. 22:00>. In the case of <2024-02-04 12:00 @America/Vancouver> or <2024-02-04 Sun 20:00:00 @Z> just regenerate agenda after update of time zone database (perhaps emacs restart will be required). > 4. For the Poll: What would be the expected behavior if we used the UTC > offset?  [2024-02-04 12:00 @-08,America/Vancouver] >     - We should know beforehand the DST of Vancouver, Obtaining offset from UTC is not a problem: LANG=en_US.UTF-8 TZ=America/Vancouver date -d '2024-02-04 12:00' '+<%F %a %T @%z>' <2024-02-04 Sun 12:00:00 @-0800> > or there would be > warnings. It seems more difficult for the user: maybe the "-08," should > be optional? I expect that both time zone identifier and offset are added either to resolve ambiguity of local time around change of time offset or to catch updates of timezone database. In the latter case it is optional, but it helps to notify you that event time is updated. >     - Case 3: After updating the tz database we would get warnings too. > To correct those warnings, should the UTC offset be changed manually in > the timestamp?. If there were 35 meetings in Vancouver throughout the > year, to change all the UTC offsets could be non trivial for a normal > user: UTC of the summer and winter would differ. org-lint may present list of inconsistent timestamps. I am afraid, in some cases you will have to contact organizers to ensure that event was scheduled correctly (either in respect to local time or bound to UTC). Communications may require significantly more efforts than fixing 3 dozens of timestamps.