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 WFQpAuDHymOdjQAAbAwnHQ (envelope-from ) for ; Fri, 20 Jan 2023 17:57:04 +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 YL8QAuDHymPB7QAAauVa8A (envelope-from ) for ; Fri, 20 Jan 2023 17:57:04 +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 C15CC1120A for ; Fri, 20 Jan 2023 17:57:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIugj-0002vk-ET; Fri, 20 Jan 2023 11:56:25 -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 1pIugY-0002v5-L4 for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 11:56:18 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIugX-0000ME-5O for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 11:56:14 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pIugV-0005Sc-6v for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 17:56:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Fri, 20 Jan 2023 23:56:04 +0700 Message-ID: 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> <63ca5101.630a0220.b2298.3363@mx.google.com> <87h6wljhce.fsf@tsdye.online> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <87h6wljhce.fsf@tsdye.online> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.089, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1674233823; a=rsa-sha256; cv=none; b=OmOo/rj7n1ytdl8r4PKzd0/5jPfuY/D2kPbr7Xye46akKQFIw4TQcho20Ha19emgV0l9z9 TQoIIjrnNcAFPKqfaSiE6+vMkDML7/ZOdGD6trkoK+MfHniuu806pPS+jGEZVtrA9JsjcK f/lLmCRH31wIL5owjEzKt30qJYtWVXRa47AQKmwDDgXrC8C8ds3Hh9DJFR9d8ROS4OGkqZ 8mwTl2iL28W3LJaT2WsvzLAkvgSk+iWgoW4gotOMPM+i0unWV8cmf6mAnx0l2jR4Gttjd6 M3OzaSq9u4Lm0QncgT6onXjUvGo4PSGXayT6gtKurtztZe5Exw14T6hrX7ZTTg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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=1674233823; 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; bh=hROR9GL4M+DdjMS0291SRSrLw/yRO/6km+JPlXGc/0o=; b=Ng9moTH28R95JtSg4IZ6/rCrajmb5YHC1GIDg/X0WU0yhuiZJz9i+R8TLgK2dLwSqwiceu HE+h72abxUhPP2cWwF43xmN0KSToqgWWhuqOyLhi3fnpIBCrs8fvJqelX/Vnd56Sr7M5tX yi5aXpTlhagnnmU4u3vIVCiE3cleNEWcPTnOAtJMlEbgWY4FrkDlkaH4oeT38o5P/Ua+yz vwkzosjmh4wied79cu4HgZ3xv7FlnaLZo2FEvZs2dZaWFNcb2B2QZrNxL+tYpDBQAGKWDC GQAX8ntXHiXKi6OhhX3bWzCqlQO+hedNXbWosqQjDwm54cCN/26s7mMfoDsObQ== X-Spam-Score: 3.79 X-Migadu-Queue-Id: C15CC1120A Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 3.79 X-TUID: tovbNv7I28to On 20/01/2023 23:09, Thomas S. Dye wrote: > Max Nikulin writes: > > Now, if Amsterdam's timezone > arbitrarily changes its relation to UTC before the conference takes > place, then everyone who participates in the conference must notice this > (or miss the start of the conference). My point is that if timestamp is stored in UTC than it becomes incorrect in the case of time offset change. If such timestamp is stored as local time + time zone identifier then application presenting the timestamp to users will show correct time as soon as zoneinfo data is updated. > A virtual conference is organized by > someone in Amsterdam, who sets a start time corresponding to 9AM in > Amsterdam at a date some years in the future and invites participants > from all over the world.  Now, if Amsterdam's timezone arbitrarily > changes its relation to UTC before the conference takes place, then must > everyone notice this?  Or, should Org, from the time the arbitrary > change is made public, simply adjust the conference time for all the > participants in the Amsterdam timezone? Both variants are possible and a planning application should support them. It is matter of negotiation between the committee and the participants. Timestamp should be stored in UTC only in one case.