From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wJWtLr8v2GOmUQEAbAwnHQ (envelope-from ) for ; Mon, 30 Jan 2023 21:59:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4HiqLr8v2GMiWQAA9RJhRA (envelope-from ) for ; Mon, 30 Jan 2023 21:59:43 +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 865383F03A for ; Mon, 30 Jan 2023 21:59:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMbEx-0006ET-Ie; Mon, 30 Jan 2023 15:58:59 -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 1pMbEw-0006E8-O6 for emacs-orgmode@gnu.org; Mon, 30 Jan 2023 15:58:58 -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 1pMbEu-0004wA-SQ for emacs-orgmode@gnu.org; Mon, 30 Jan 2023 15:58:58 -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 0000000000103A93.0000000063D82F73.00007262; Mon, 30 Jan 2023 13:58:27 -0700 Date: Mon, 30 Jan 2023 23:55:47 +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: <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> <63d6d931.170a0220.84f9f.11fd@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <63d6d931.170a0220.84f9f.11fd@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: -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=1675112383; a=rsa-sha256; cv=none; b=d29HQaz8rpUhN13oEUAfnABcrKEmIFIhCAg8nXPPIUbglBw2xzu89MhXvAUp4kU9Jz+rFK 7GkHnmtoxirxK+6fZTt28pV/WodWl3mC1/nyBzO+wWKoO/czbE8Ujfby0538M0LSJps9Md 3cuqNKARULv8hW3LBcrgfSO+FlSaGmbIeiR0gXcq59Hvc2g5Uw4qYuYrFMzUkUt0RjDX9B uDOUDShf5NYtPLYYLcKsKun/L4JUi9BVMLXAaGhO5BOPferpW4j3M+ZxPKuAthLW7U+95d x+NjE0H3r4SedU7SYABUEvSFpYAd4YWR3y1pi9Y+/wLrONs+IZBlaaU6isJ3BQ== 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=1675112383; 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=8NVegNVOZqMviRlSudJqgzq5iAphAyJ5Ns6Ps9mVBkA=; b=bXDdvDMiqvSPx33WlsSd7hhqkwlWjosqTnYEFty3/ud6n+quwPOX0xiBV3VtUtxCvKMCbr Dhj4LNBo3X90BIkO/Dg/+I2jnPzp4eBirS/B14flvXtsLzV1XP4aVmz63LzIMHuwDMbQgT RBqbDPGVT5CqEb6L2O9ATdL/OgnMf7YfAXeyGcSwu5yVABN2nUTdP3lELBqONwSOn7rLBw liV/A4pAWdH6dGf7p5zvmkVHPL6dUWkfz3cwquxqH9SDyFJTSZjDDvxWMDI8p9aaTFMpwL aSOlOlCqfLlNloihqELpAnQNaIys+6yqGjcntV3Txxt+TAmyUxMA0fa2wstpTA== 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: 1.92 X-Spam-Score: 1.92 X-Migadu-Queue-Id: 865383F03A X-TUID: Q7mwat9c+pHk * Tim Cross [2023-01-29 23:38]: > Yes, a timezone is defined by the offset it has from UTC Other way around Tim, the UTC offset is defined for the time zone. Time zone is not derived fro UTC offset, that does not work. UTC offset is derived from time zone. > Yes, a location time zone may change due to various reasons, such as > daylight savings time, which also means the offset for that timezone > changes. Including that offset for that time zone can be changed for political reasons, and did change in past, and some time zones may multiple UTC offsets. > However, it is the time zone definition which has changed. Yes, and that change is about UTC offset. As time zone represents location but UTC offset must be tied to it, otherwise how would you know what time has the time zone? > When you specify a date+time wiht an explicit offset, that offset is > fixed. It is fixed for that time moment. I have not said anything different. I am only worried that if calculation go straight from UTC offset to UTC offset without observig time zones, one will get proper UTC time, but not proper representation in users' time zone. I do believe that Org developers will make right decisions. > That date+time is fixed. It will not change when daylight davings > comes in or goes out because it isn't a time zone. It is only an > offset and has no location reference and therefore no time zone. For the above, I have already sent a map, by only observing the map, one can see that time offset is directly related to time zone, it is property of time zone, and it will change depending of political changes, and it does change with daylight savings time. I have given enough references, feel free to read it. What does not change is the fact that UTC offset representation will accurately provide UTC time. >From UTC time, by using user's time zone and various embedded parameters one could arrive to user's local time, including users UTC offset. Excercise: When there is daylight savings time (clock goes forward or backward), it shall be clear that UTC offset changes as well. That means one hour more or less must be accounted for in every calculations of Org Agenda. But by using UTC offset alone, one cannot even include daylight savings time changes! As for that one needs time zone. Here is another good reference: https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ ,---- | Our Example | | America/Coral_Harbour is a time zone (for simplicity, I will focus | only on IANA* time zones). America/Detroit is a time zone. With laws | as they are now, the America/Coral_Harbour time zone has an unchanging | offset of -0500, or five hours “behind” GMT, which for our purposes | here matches UTC. America/Detroit changes during the year from an | -0400 offset to an -0500 offset. So sometimes, the good people of | Coral Harbour and the good people of Detroit have the same | offset. Sometimes, they don’t. `---- What do you think, is that information true? Does UTC offset "change" or "remain fixed"? Is it possible for programmer to convert UTC offset by using direct calculations? Or programmer needs to know information about time zones? This makes calculations of Org Agenda or future time stamps difficult when using solely UTC time offset. Time offset is best expressed as representation of time at that time point, and is always derived from the time zone. > Saying that an offset is a fixed value is very different from saying > that a time zone has a fixed offset. I think this is where your > confusion is coming from. I said neither of those. I never said that UTC offset is fixed. I am trying to give you references that you understand what people agreed on this planet. I never said that time zone has fixed offset, some time zones have it fixed, some not, as UTC offset changes for daylight savings and political reasons. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/