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 aMPmHxu/2GOHdAAAbAwnHQ (envelope-from ) for ; Tue, 31 Jan 2023 08:11:23 +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 wE4EHxu/2GPlBgAAG6o9tA (envelope-from ) for ; Tue, 31 Jan 2023 08:11:23 +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 DDF1026564 for ; Tue, 31 Jan 2023 08:11:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMkmc-0000Kl-R3; Tue, 31 Jan 2023 02:10:22 -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 1pMkma-0000Hn-HO for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 02:10:20 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMkmY-0001co-Lp for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 02:10:20 -0500 Received: from localhost ([::ffff:154.228.136.227]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010394C.0000000063D8BEDB.00001B5E; Tue, 31 Jan 2023 00:10:19 -0700 Date: Tue, 31 Jan 2023 09:08:20 +0300 From: Jean Louis To: Heinz Tuechler Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Message-ID: Mail-Followup-To: Heinz Tuechler , emacs-orgmode@gnu.org References: <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <63d43ec5.630a0220.87fac.44e2@mx.google.com> <871qnd979o.fsf@tsdye.online> <0597910b-9b01-3c0c-5d06-da171e0de4cd@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <0597910b-9b01-3c0c-5d06-da171e0de4cd@gmx.at> User-Agent: Mutt/2.2.9+54 (af2080d) (2022-11-21) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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=1675149083; a=rsa-sha256; cv=none; b=FOabGraYQRPS+Rb2HMzq8eXJjw8xUSjb50+uW5/JpTPfRIFU/uYPVIyx9UAXB6u853G3Ww pSe3ahn5yBqKNluO2ho3rWgISry29lKl+8yCihNSK9f9v7DxkUNphSQM7Bbb/whgbq3kA5 zPz7zTMEvKHREQvJDmG2w0mtW7e3LjXPvWB2lHHbX5a/WV+Y4EWbN8Ll+n9rRo7iZh0FeH zevQUp067c+IsMVR+zxBrJZgCIkSV9vS05kqhfv7DlA/wTGIWqeVFBld6lyj3GkxyYDRuq 5t591u5+sXYGE5nKcGH6sEPe4cCgXy1GGcRPZUVX/A3yXrePlshnRPmEWSAtiw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675149083; 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: 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=pySOtM1rBW7AdeeW5CkOyDox8VV2gJXtB8qXrgLd+kM=; b=O51dqnrilMd7oByLsUwOIrQ5lCC1YB+yN8mAyRhcnJaBuTi2gpDZfPyPW2P8nEIM8D/Aiy Ku4r+VaqXi0RGxJfsZKmvTyB8mNQnoVQNwEvIr0FxXIlcHd8tPWJXVt7oJKeMXXIpwJWnT g4Zom9etv4zbkNCo7Jx7t2V949UpJb1wYtd2ulB9czbJ07LGP/D+dOFyKGnBmXkOnIKzxN U9V3lB6LmAV3yCmk1AlCMbHH+xgfp48py44GtBOGe5/CdIDV6AOcqnRVt0fEkZVxg5S/ff ID/DUq7pqaLEyp5r1o9uwqrfSm8M3aA9AHKumyP0odkjNoV8+qkdBDYqorIFMw== Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -0.88 X-Spam-Score: -0.88 X-Migadu-Queue-Id: DDF1026564 X-TUID: meRgcrt6qceW Dear Heinz, Thanks, let me see. * Heinz Tuechler [2023-01-31 01:02]: > Dear Jean Louis, > > it appears to me that you mix two aspects. I agree with you that a time > zone needs an offset from UTC to be defined. Consequently the definition > of a time zone requires an offset. Yes, that is good our mutual understanding. > But an offset does not need a time zone to define a time. I am trying to understand what you wanted to say with the above. Before representing time with the UTC offset: --------------------------------------------- To derive the representation of time with the UTC offset, one needs time zone, as UTC offset is defined in the time zone. That is what you also said above. After representing time with the UTC offset: -------------------------------------------- That time is defined, and at that time point does not need time zone. I am not concerned of time representation after UTC offset has been derived, but of programming calculations to users' local time, as for example in Org Agenda. > For example, true mean local solar time of a specific longitude can > be described by UTC plus offset. Solar time - Wikipedia: https://en.wikipedia.org/wiki/Solar_time By meaning that solar time should be related to longitude, I am totally with you Heinz. It is also true that one could disregard the definition of UTC offset from the political reality, and calculate it absolutely. That condition I have already mentioned, when I said, that means we are making "new type of time" in Org, if we start calculating it that way. The meaning of "UTC offset" is however, political. Please see the UTC offsets here: https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png Look at the map, find Kazakhstan with UTC offset +6 on the same longitude with Russian Federation with UTC offset +5. Observe Kazakhstan with UTC offset +6 on the same longitude with China with the UTC offset +8. That alone should tell you that solar time is not really related to UTC offset, but we could say it is "approximate" with few hours more or less. Of course you can describe solar time with UTC offset, but do not assume it will be accurate. > I agree with your criticism of "They refer to local *solar time* at a > particular place." This is written in > https://en.wikipedia.org/wiki/UTC_offset , but not even there the > description is consistent. We can say it is approximate what they mean. > Of course, for every finite offset, we can find a corresponding > particular place (a longitude). I wish it would be so, but it is not so. It is approximate, just look at the map. And please tell me if after this you still think there is something wrong? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/