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 6KJFOVGJ2mPjpwAAbAwnHQ (envelope-from ) for ; Wed, 01 Feb 2023 16:46:26 +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 OMtKOVGJ2mOtTAEA9RJhRA (envelope-from ) for ; Wed, 01 Feb 2023 16:46:25 +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 AC95A7D6E for ; Wed, 1 Feb 2023 16:46:25 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNFIv-0003Gq-LY; Wed, 01 Feb 2023 10:45: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 1pNFIc-00038o-6l for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:27 -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 1pNFIU-0001rD-5D for emacs-orgmode@gnu.org; Wed, 01 Feb 2023 10:45:19 -0500 Received: from localhost ([::ffff:197.239.7.190]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000103957.0000000063DA8911.00005175; Wed, 01 Feb 2023 08:45:20 -0700 Date: Wed, 1 Feb 2023 18:28:23 +0300 From: Jean Louis To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda) Message-ID: Mail-Followup-To: Ihor Radchenko , emacs-orgmode@gnu.org References: <63ca1283.170a0220.5bc81.0fdd@mx.google.com> <87pmb9k8oi.fsf@tsdye.online> <3035CDD5-41DD-4516-9E4E-9E0DF16BE2E0@gmail.com> <87lelo8c9r.fsf@localhost> <2150768.1675077958@archlinux> <87tu063ox2.fsf@localhost> <87h6w63jgg.fsf@localhost> <877cx1lfox.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <877cx1lfox.fsf@localhost> 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=1675266385; a=rsa-sha256; cv=none; b=QpNiN9T41HAtl2Vtovub1snIaJg3yAAWm0IjXbjrNSsF+JLd3kxF8CyvKO3X5l7NA1u5aW ckHnuxgL24QAuf/3jkGwoBmpZHSrkR5qGG27kkT41ncJ9OUUde95VsgOfRs9JfZN91IfTQ KlmHJlqiZxOp0uZzbQSk7j6nFlIK9SYIEXhhidTWhNBMRewrCuDp1zWhB2KJ0POgcRig9l wcc7JKcUCP0LD8uqvu0JITUxvlIDouNySyzwbPrQLoCRAejkr0GqBfZY3O4ImGIrpbxpjD xWJfaFI0Yx+iObe08MsaYCZega4CwFdAzsXBibauYx41oupLhZPf93eQzcNoZg== 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=1675266385; 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=LdMWzg0FLnU6mn5tIVPRUYRmtN3agTi9pOzTHyLiegc=; b=ILdjsyIiYmFRLhV5VmXnmytCufyHi3Wng0z/9hkkrGxA7ewGC3W2lFcgXeQ+aNTQj4L8W/ QpxaDBzYw3JsrLF9/Pv/YXfkwSD2HhISoA2MBNaVIiLOOpfWhRZcZnlNMzZUxp1lVBuffy 7CFJIFlxU6VsezrR7TA8oVVgKBulvG8qib6SjnztmDz5OJJusUjfcj/JOd/3izS3jD27+c fWuFqQxnHyuVqMWZJ0Mh6Ixezv8aaA4n902U/GESpk05mpKM+RLrqBr2B97/04hPOJ4RiA hz5Qk4ZjHSD1Iv/rN8gNoUHqRDDsHNMSx/wCtj+V8Bv3N6aH5UmEntt4TBylLA== 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: AC95A7D6E X-TUID: RVqEYbYt8kGk * Ihor Radchenko [2023-02-01 15:42]: > Indeed. Org is used by a variety of users with different needs. What I > just demonstrated is that specifying the time zone is not always > necessary in timestamps. Specifying time zone in time stamps is not necessary! But using the time zone is necessary if developers wish to provide accuracy of time calculations for users. Using the time zone is built-in, it is just matter of representation of time at export or exchanges. And time zone could be changed from the default system time, inside of the time stamp, if not there, inside of heading property, if not there, inside of the file time stamp property. That way majority of time stamps can remain how they are with addition of specification of time zone property. > Note that my proposal allows specifying the time zone when you need > it. Thank you! That is good proposal. > Or not specifying it and specifying the UTC offset only. If you mean, specifying _local time_ plus UTC offset, then that is not how you can exchange information with participants in meeting. That is unsure. But if you mean specifying _UTC time_ plus the UTC offset, that is alright to derive local time from it. Preceding condition is that such UTC time plus the UTC offset was calculated correctly. And there need not be the ultimate goal in Org that all kinds of time stamps can be calculated for the future. That shall be the job of the function to verify if the timestamp can be re-calculated or not, and function may warn the user to update it with missing time zone. Read "Putting It All Together" https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ Are you going to implement the connection to time zone database? -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/