From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 +AgoHRu/2GN/PAEAbAwnHQ (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 mp11.migadu.com with LMTPS id gPIuHRu/2GPFhQEA9RJhRA (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 E715126880 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 1pMkme-0000LH-FU; Tue, 31 Jan 2023 02:10:24 -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 1pMkmd-0000Kn-1L for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 02:10:23 -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 1pMkmb-0001co-4F for emacs-orgmode@gnu.org; Tue, 31 Jan 2023 02:10:22 -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 000000000010394F.0000000063D8BEDF.00001B6D; Tue, 31 Jan 2023 00:10:23 -0700 Date: Tue, 31 Jan 2023 10:04:05 +0300 From: Jean Louis To: Tim Cross Cc: Sterling Hooten , "Thomas S. Dye" , 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: Tim Cross , Sterling Hooten , "Thomas S. Dye" , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, 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> <63d6d931.170a0220.84f9f.11fd@mx.google.com> <63d83f1d.170a0220.f1df3.e85f@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <63d83f1d.170a0220.f1df3.e85f@mx.google.com> 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-Flow: FLOW_IN X-Migadu-Country: US 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=T2V9XkgH+PiaiDLD9jnGGWA53qBuX3K/PUgfTmbqh5E=; b=mtheRS4qTUYswHjHzxEXYDIUjtR0iS5aPE9MVi40vh7zXlSlF63pVl4g5kGo+qJgr6tXJI 4xmO8ovOYurANTxtH7R3QVnpxygHPJkVd+wbSSFh+S/SlLtci0YXQMwCt/VQbOcPhlEFy7 dyWqNZh6ZWK3JVAIiHyZ/Eup7o19QyM2Te073oG//Ut8xB3EfThq7M2Msz9zhELggEKqLJ 0g6QX0DzmDjutQCn6SENcExdSividTm9tbw14ul0kgaRiaBFEfqHYLYKttpurNAaP4tk8s fNgq8hauVupZ/pcn7oHaTE4g76hxF8EcG41vXwb8jkhK5waiqixr1OHHGtEadQ== 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-Seal: i=1; s=key1; d=yhetil.org; t=1675149083; a=rsa-sha256; cv=none; b=ED9sAO5zrV+xoxQbT2N42zU32EGw1cJ8qLT2stWSnSt7TJrbLiOjHX/O7188989mvuae4v qH/NSODVlrXYgXWmUCTsTOtDHsk7S1WZ6gD1dxBSrv6crvSZWH7lwkK+rJ5ZWp1/uW9iAA Zx4BOeT8MRLZbCQSQCP6ZKWzcVCcYIwfqM9D7qW8uLTG9O4eRUxlxczZ8QVtMs/YGdMMIK 0LDgYLJpfHbcP6rUo57MscnLqmYsx03WjIh9OFKmvxCQIjx4ZMygnVJu11IC7bY+kAMWM6 Gq41ifFJ8FR5dI1uGx06mCQ2hnILt+mxFf8Ufnls6R3RtHBwf2DWgGjEihOafQ== 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: scn0.migadu.com X-Spam-Score: -1.68 X-Migadu-Queue-Id: E715126880 X-Migadu-Spam-Score: -1.68 X-TUID: bIfSpD5GxGe/ * Tim Cross [2023-01-31 01:05]: > Jean, > > you have a very irritating habit of changing the topic of the discussion > in order to push whatever you feel you want to argue about. My response > to you had nothing to do with all the irrelevant points you insist on > repeating despite numerous attempts by many to explain why what you are > sending is adding little value. > > I was simply responding to your response to Sterling's glossary of > definitions where you argue against defining offset (the term) as a > fixed value. > > I will not be engaging with you further. UTC offsets have been assigned by authorities, that they are political, change due to daylight savings -- and for that reason cannot alone as such be used for calculations of time, for example in Org Agenda. I fully understand that representation of time with UTC offset alone is as such fine and good, never said anything opposite. Adding some hours, days, as absolute time to it, or deducting, it is of course always possible. I have given facts, and references with the sole intention to help in understanding so that Org programmers do not start relying on UTC offset alone, as that is not how other programs work. My intention is of course not what you stated. I have not get bad intentions. Please do not assume it. You got references showing that it is politically related, that UTC offset does change suddenly, and for that reason one cannot just use it for calculations in program. I am fully aware and never stated different, that once you place UTC offset as representation somewhere in text, that it is offset from UTC time and that time point is fine and remains fixed. What I am saying is that calculating that time point to local time is tricky, as using UTC offset alone is not going to give accurate local time unambiguously. Sometimes it will give, but sometimes not if programmer uses direct calculation. "fixed" is thus only fixed in context of representation. I was thinking we speak here of using time objects for calculating times in future, not only of representation, as I did not argue about it. UTC offset is representation as it has to be derived from time zone to be represented as such. Provided that program knew how to derive correct UTC offset, that is "fixed" as representation. Programmer can now add some time or deduct some time and directly added or deducted time will also represent some point in time. But will it be that time that user was thinking for another user in different time zone? Unambiguously is not possible to use only UTC offset for such calculation, due to reason that UTC offset changes how authorities decide on it. Let me try to make exercise example both for me and other people, and feel free to correct me: From: https://www.timeanddate.com/news/time/europe-starts-dst-2022.html ,---- | Daylight Saving in Europe | | Time changes in Europe are synchronized. According to the current EU | law, DST starts on the last Sunday of March and ends on the last | Sunday of October. Participating countries are: | | The European Union (EU), including Bulgaria, France, Germany, | Italy, Poland, and Spain. `---- - Last Sunday of March in 2022 was 27th March 2022, or 2022-03-27 - the clock forward had to be done at 1 hour UTC time on March 27th 2022, because Berlin before 27th March 2022, was with UTC offset +1, that time should be 2022-03-27 01:00 UTC time, which is also same as Berlin time. - Let us say one second after 2022-03-27 01:00 UTC time or UTC +1, the clock will not be 2022-03-27 01:00 UTC, but 2022-03-27 02:00 UTC, loosing one hour, as clock moved forward. UTC offset changed suddenly. - person in Berlin plans meeting for on 26th March with somebody in China, for 27th March 2022 at 10 o'clock, how is he going to represent this? Let us see, maybe as following. <2022-03-27 Sun 10:00> - on 26th March 2022, the UTC offset in Berlin was +1 - on 26th March 2022, when user exports that appointment, the time was for example 16 o'clock, something like 2022-03-27 16:00+01 because UTC offset was +1 at that time. - If Org programmer decides to use UTC offset only for calculations, then the program will know that UTC offset in China is +8 hours. - What will program do? By using UTC offset only, program will know that now is 2022-03-27 16:00+01 and that timestamp like <2022-03-27 Sun 10:00> is also with UTC offset +1 (which is not true). But program would think it is 2022-03-27 10:00+01 if program uses UTC offset only. - Program may wish to provide new UTC offset for Chinese user, by knowing that in China on 26th March 2022, at 16 o'clock is +8 and not +1, the difference of 7 hours will be added on the time stamp of appointment, which is 2022-03-27 17:00+01 - However the time of 27th March 2022 at 10 o'clock Berlin time the time in Shanghai was 16 o'clock. - While Chinese user was in restaurant at 16 o'clock and waiting for appointment at 17 o'clock, because he has got calculation with UTC offset only, he will be surprised that he missed the appointment. - Because Org used UTC offset for calculations considering it "absolute" or "fixed". Conclusion: ----------- Using UTC offset time stamps alone cannot be used unambigously to represent time for Org Agenda or shared appointments or meetings, due to possible political changes and daylight savings times. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/