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 0BCuAgtp32NGZgAAbAwnHQ (envelope-from ) for ; Sun, 05 Feb 2023 09:30:03 +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 UKK1Agtp32MrEwAA9RJhRA (envelope-from ) for ; Sun, 05 Feb 2023 09:30:03 +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 C154D2DE20 for ; Sun, 5 Feb 2023 09:30:02 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOaOw-0005Pt-0N; Sun, 05 Feb 2023 03:29:30 -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 1pOaOr-0005Ox-2V for emacs-orgmode@gnu.org; Sun, 05 Feb 2023 03:29:26 -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 1pOaOn-0006ug-VU for emacs-orgmode@gnu.org; Sun, 05 Feb 2023 03:29:24 -0500 Received: from localhost ([::ffff:102.83.69.138]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000010B847.0000000063DF68C0.00000F3E; Sun, 05 Feb 2023 01:28:48 -0700 Date: Sat, 4 Feb 2023 22:45:33 +0300 From: Jean Louis To: ypuntot Cc: Org-mode 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: ypuntot , Org-mode References: <724af979-3825-4818-bc3b-76649752a004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <724af979-3825-4818-bc3b-76649752a004@gmail.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: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675585802; 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=gOYPkK6jMLJKS60ymEsHCbzlB5c3Cn96zaiQVrcThl4=; b=IS+yJCBqgQxyr0gqTsnFgpg1ToptcjYWlrBAMrvPYbaPW1e8ki0oq6Ry3ZKHC0ngDRzJ5j aDwAz8sP2RIo7yfuFtjL55XMnBpQbLDbZcCvzqD0Xr7omYQBR2ADM9HzAUjKjBDhYnP0ko 2LvmMncf7hRGLvBzmgBpWzQ7Owj7xNL+5KTXFR/bQbfWeloNaY13QB+GlVgXWTWx8EsVQ0 UckRE9D+vAbFgDX+OubjkY8GOkEUtJnrj6iFGDDby8Ox0rvEVPns3NcjJL3LsOh0qn6ipi ndt73Fl2h2La1SwZVuf1D4UIBC82581JjWCeQ6ZMDsDSif1AoUzT/hlmN14j2g== 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=1675585802; a=rsa-sha256; cv=none; b=cg1HkFJzsUCehYfjev0F4pn3WLo/qDXPej12eiz59PWaw/TV4i0tyo8YLiPZCqSNmhvFpv 92fSTPjLGUpsCwtRPPROmXEYhYucC/evxQ/g9S+YcaMhLvdINJkoy6/dfQJKLkuNqJj3es X5tsnXF/azulQwzZK7E1AIIGCPSqElVw9qURX62lL61v0iYpdyBONhbNha5aXvmiBmzgZE mWh3wN2Vme/dtYhg48emVJVnwJ9lgidGVj2DCjb7NAyfsKlK1SuSnyu2CSvR9TrZJvfj7y l+FAzQJ3+Cjp+12TV3LtUfa6EFsC6+gB53wMkgVPM3UsreEuATf4laptNh7LKw== X-Migadu-Spam-Score: -2.89 X-Spam-Score: -2.89 X-Migadu-Queue-Id: C154D2DE20 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-TUID: 6vtZjRvxNDOQ * ypuntot [2023-02-04 22:01]: > Great link! > https://spin.atomicobject.com/2016/07/06/time-zones-offsets/ > > "Given a local time and an offset, you can know UTC time, but you do > not know which time zone you’re in (because multiple timezones have > the same offset)." Exactly. > So, given a time zone you can know the offset (Google it, for > example).. Then, given the time zone and the local time, you can > know UTC. If orgmode gets the UTC there is not ambiguity. Majority of people do not use UTC. Having time displayed in UTC would and will confuse too many people, unless such time is only for logging purposes. But Org timestamps like DEADLINE, SCHEDULE, are really meant for a human. Internally, in calculations, program shoulde find time time zone, UTC offset, calculate, go to UTC, again to time zone, and again represent proper time. And if not that way, in any case there is complexity involved. Here is also good reference telling people how to program and work with time zones. Working with Time Zones: https://www.w3.org/TR/timezone/ > But, that would mean that the offset related to the different time > zones must be downloaded and updated from some site. For past timestamsp, one could store such as UTC time, and such time may be easily represented in presen time, it may be viewable in local time if computer program consults the time zone database. For timestamps we are making now, to record something, when it happened, we could use UTC time, but only for logs and similar, not so important time representations, which we will not revisit too often in future. But let us say for some future, timestamps in DEADLINE, SCHEDULED, those timestamps related to human, the UTC offset in this case cannot be so sure, because it is in the future, and it is vague as it could change politically. So the future will know what will be the UTC offset. > As you said before, that offset can change. For example, peninsular > Spain has the same time as Berlin, but as this doesn't make much > sense, it could change, so updates would be necessary. That is right. Even the time zone designation (name) could change in future, but for that reason, if we use today a time zone, the future time zone database will know about time zone that (was) defined today, and computer program will know how to calculate representation of the time in local time in future, for the time of today. Time zones are updated regularly, but we cannot be sure of it in case of atomic war or other planetary commotions. ☹️ I wish people could love each other more. ☮️ -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/