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 WNK+Obgv2GM2FQEAbAwnHQ (envelope-from ) for ; Mon, 30 Jan 2023 21:59:37 +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 KG+7Obgv2GO+0gAA9RJhRA (envelope-from ) for ; Mon, 30 Jan 2023 21:59:36 +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 A1CC4413F7 for ; Mon, 30 Jan 2023 21:59:36 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMbEj-0006AF-0Y; Mon, 30 Jan 2023 15:58:45 -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 1pMbEh-0006A1-2z for emacs-orgmode@gnu.org; Mon, 30 Jan 2023 15:58:43 -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 1pMbEf-0004qk-68 for emacs-orgmode@gnu.org; Mon, 30 Jan 2023 15:58:42 -0500 Received: from localhost ([::ffff:197.239.7.66]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103955.0000000063D82F62.00007225; Mon, 30 Jan 2023 13:58:10 -0700 Date: Mon, 30 Jan 2023 22:37:51 +0300 From: Jean Louis To: "Thomas S. Dye" Cc: Tim Cross , Sterling Hooten , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Message-ID: Mail-Followup-To: "Thomas S. Dye" , Tim Cross , Sterling Hooten , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org References: <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <871qnd979o.fsf@tsdye.online> 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: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-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=1675112376; a=rsa-sha256; cv=none; b=F/jGnITcrd2tbk91oBcsyldi7AypxLuCchOnbrsu+P8adTQgWjRClixvQLsOdwLLpsJ6O5 S88Xg24NjqOgZ1hulq3sChhH6u3rFkb6orR9b55N86cq1RK7lkn8c13oI36OQD7OMkPQ1x GHP30mcUJ8BGAvYgqkt/yk9dWUbz9ZNN6fd2OxOQstFykVMLYlB36K0XAij4c8wP8+sU59 wot2Auz8MkVCk67qUyIyjzS/PbbTuACqe1+X7VEWlUUnWvIgq0xZXqMT3SvhHMeGTw36oO M6pDyAQC7JfciYA7ybp+n564oRbAiSXBnsPMxsH1DhY/agIIucBIbKhBMTSIGA== 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=1675112376; 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=sGtrv0mqhGigo56Izk06/lLjwsZp2dhqJ7/tF/hijJc=; b=ZWb2MuC99Ux/1qjPRdeAv6VolpC2f35YTArgwZFE1B5e1YxFKlL5sqLVOa3t2G5uxL6/Ht Bs2Zu3PzsS1HxqtLujb43jcyudLDbTfV759+zaGIeCZDz8koCymhRYdFrMyDD1t7ItpTcX UXEQgfTWdgrYeA4/EaYWV8IY+sUfiygM7EKWDvSpmoBMCV2jVqfaymO2ibgNG+wS/1rSH9 JgXZ69J2jPDhO/ZjWloLE0J1H+v6S3cnrO4MIBuzS7iGwpPKTGr/TCs0fMZ5km5oR8RJs+ rHaYjbauuc6dtrm04KU5sF1vTcwtr6xBTjTfKOZmZfhVv57TFCgqvWFx5cyj0w== 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: 2.42 X-Spam-Score: 2.42 X-Migadu-Queue-Id: A1CC4413F7 X-TUID: 7Stdo15LUyXQ Dear Thomas, I give my best to find references for you and explain you the possible problem in calculation of time stamps. That problems exist is clear. To solve problem it is important to first define it. And when there are developers reading it, I wish to provide best possible references for the sake of people using Org mode. So let me gently try explaining it with different words. > UTC offset exists without time zone. I have already stated that UTC offset is property of a time zone. Single time zone may have different UTC offset. A time zone must have UTC offset as it's property, as how else would people know what time is in Berlin/German? Is it by guessing?! So for that reason on this planet countries agreed politically to define one or more UTC offset for every time zone. UTC offset is thus always derived from the time zone. That it "exists without time zone" is something individual, but when we speak of UTC offset, we know that it was derived from time zone. What we cannot know unambiguously is from which time zone it was derived. > UTC is absolute time As we know absolutes are impossible, especially about representation of "time", we people have only agreed on how to define UTC time, that is what we count internationally. Let us assume it is absolute. > and offsets from it do not refer to political time in a time > zone. It is good to observe the map to understand if UTC offset does not refer to political time or maybe it does? All time zones have their UTC offsets, as otherwise we would not be able to calculate time by sole name of city like Berlin, so Berlin must have defined UTC offset, and all time zones, from which UTC offsets are derived are politically decided, this includes UTC offset, which are very much political or in other words they are decided by people in power or in authority. > They refer to local *solar time* at a particular place. They maybe should so, but that type of solar time is also politically decided, it is not something calculated or really accurately pinpointed time. You may observe it on the map, and decide if it really refers to solar time or solar time is politically decided, or maybe something else? Solar time is also not much relevant for Org, as what I would like to see in Org is precision with time calculations. While I cannot guarantee for accuracy of these maps, it will be beneficial to look at them and make a practical exercise. Look at this nice map with time zones and UTC offsets: https://qz.com/wp-content/uploads/2015/03/map.jpg?quality=80&strip=all&w=3000 I guess that only by looking one can see that it cannot be possibly accurate "solar time", but we can speak of approximate solar time, as differences of 1-4 or 5 hours in solar terms is nothing so special. Anyway, solar time is not important for programming calculations. What we wish to observe is not to make mistake in programming by using UTC offset incorrectly, as IMHO, that alone would be poor choice for Org developers to stick to it. Excercises: ----------- 1. Observe that tim zone in Iran has offset of 3.5+ hours, while North from Iran at the same Earth longitude in Turkmenistan, there is offset of UTC 5+ -- solar time can't be accurate that way. 2. UTC offset depends on time zone, it is the property of time zone. See the map to understand. 3. UTC offset may be changed by decisions of authorities and is dependant on daylight savings and political changes, as it has to be derived from time zone. 4. By using UTC offset one can find UTC time, like Max say, that is for many applications alright, but it will not make it accurate. I am reluctant to accept that UTC offset is enough, unless it is demonstrated that it will bring the intended purpose in Org. As that is just one parameter that is derived from time zone. That is not how other applications work, they will either store time in UTC, or time with time zone representation including UTC, plus including the UTC offset. One need time zone to understand and calculate future times for people who change time zones, for example in Org Agenda, as by using UTC offset only, one would need to first convert it to time with time zone of the user viewing that time, and then to UTC offset of the user viewing that time representation. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/