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 EIzsA+1TxGMFSQAAbAwnHQ (envelope-from ) for ; Sun, 15 Jan 2023 20:28:45 +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 uDkQA+1TxGNzAwAAG6o9tA (envelope-from ) for ; Sun, 15 Jan 2023 20:28:45 +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 CBD1B9A56 for ; Sun, 15 Jan 2023 20:28:44 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pH8fN-0008AZ-0C; Sun, 15 Jan 2023 14:27:41 -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 1pH8fL-0008AO-QS for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 14:27:39 -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 1pH8fK-0006H2-0x for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 14:27:39 -0500 Received: from localhost ([::ffff:197.239.8.177]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D77.0000000063C453AC.0000258E; Sun, 15 Jan 2023 12:27:40 -0700 Date: Sun, 15 Jan 2023 22:26:54 +0300 From: Jean Louis To: Tim Cross Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Message-ID: Mail-Followup-To: Tim Cross , Max Nikulin , emacs-orgmode@gnu.org References: <63c287ca.a70a0220.4bd14.873b@mx.google.com> <63c2b760.170a0220.56455.a114@mx.google.com> <63c31663.a70a0220.3ab1f.a9e2@mx.google.com> <63c3b1a4.a70a0220.225b1.83fe@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <63c3b1a4.a70a0220.225b1.83fe@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-Country: US X-Migadu-Flow: FLOW_IN 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=1673810924; a=rsa-sha256; cv=none; b=hGjZMOTd+EnbGj0t1ztc0Z1GfVapfAV5Mdxln/wNiuX2t5EWR07M7tmiRxs/GBMHuriLZs WDkNss5Ax1drKFtd6hVNr4oRCIR6QPNywEFcWLFsTCka04k+9Myrq3W5SubVedNcOOJymg oFX4opOKGP/wcbYW+tVzlBJ5yqG3+iUMcFeVzbF0PAUvhbK2fB1Na/xxGC5hbqJowm34cN obTHm6TVFL4hq3UpbOUpQ4rM3PCdpVRTDkJScQwYAE044oCihQklA1ld7CiXJikdG+v0/A CzUrTOGzmRjey1t2nSyESdhzLbGyk9vm3nkyAurdLxDdjsyFhjxSSdnokr6ENg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673810924; 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=Ru4g7shJd5wWCZuWu12fctTWWtybRTJQT+A3QJ/fQP8=; b=ll4BfKEkHLre15eNAY+Cpv0N4wzjMzwgmw4Kq9jrR2Dyuwiu93RsT6DorP9J240cuOgNA/ UUNySMyjCuADWXgdSE2/HhVYaKlnuV+Pq6wR93Gx/lHNRFUTJYN6Y3QWxBYucP/3f5qQGD 4sqX3nlGNciqdF3IfAXIYVKC6NlmGnFYPIaxTPSW+1o/1zN5HbPsg5Ogeqvo7jtIqq2oB9 AFMh1BGJ4v9blC8i0utan9+M03IChe+m9jbh1POg3PHerRjpmSjpdx9D3gdeP/+A/JEnwf N/y63AZ4JsBddo7JZmRbrXm1VXJAjkeycaYfZbCfpquLzDon5d7sZSg+cBWPJg== X-Migadu-Queue-Id: CBD1B9A56 X-Migadu-Scanner: scn0.migadu.com 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-Spam-Score: -3.72 X-Spam-Score: -3.72 X-TUID: Zhcf0ClhBbwz * Tim Cross [2023-01-15 10:58]: > WRT future timestamps, we would probably have to take the same > approach as postgres i.e. the timezone rules in force at the time > the timestamp is created are assumed to be 'forever'. While this is > not true, it is really the only solution you can adopt and you just > have ot accept that there is the chance that the rule will change in > the future and the timestamp will then be incorrect. Not sure if that is so. It is about representation. Database user in different time zone would see different time in his time zone, while user in other time zone would see it different. This makes more sense for people then using UTC, which is confusing for people and which would imply that people somehow have to convert UTC to their local time. Isn't it? Imagine online meeting with 2 people in different time zones, they share the Org heading with time stamp, but when user opens that Org heading in Florida, will see different time according to his time zone, while user in East Africa will see different time. Due to correct representation, both users now know when is the meeting taking place, and they meet in same time. If they would share UTC time, or any time without time zone representation, they would get time coordination difficulties. The type TIMESTAMP WITH TIME ZONE in PostgreSQL is always stored as UTC and time zone rules are not forever. The type TIMESTAMP WITH TIME ZONE automatically converts to proper time zone. One could think for Org to simply become able to designate time zone somewhere, be it generally for Org file or/and specific heading, or/and specific timestamp. Then implement function to transform time to UTC, and then use libraries or Emacs to transform UTC to designated time zone. https://www.postgresql.org/docs/15/datatype-datetime.html For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone. When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone. To see the time in another time zone, either change timezone or use the AT TIME ZONE construct (see Section 9.9.4). Conversions between timestamp without time zone and timestamp with time zone normally assume that the timestamp without time zone value should be taken or given as timezone local time. A different time zone can be specified for the conversion using AT TIME ZONE. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/