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 gPZQM5c4ymMHIwEAbAwnHQ (envelope-from ) for ; Fri, 20 Jan 2023 07:45:43 +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 5s6RMpc4ymNxegEAG6o9tA (envelope-from ) for ; Fri, 20 Jan 2023 07:45: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 9DBB23E9D2 for ; Fri, 20 Jan 2023 07:45:42 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIl94-0002Ln-2S; Fri, 20 Jan 2023 01:45:03 -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 1pIl8p-0002Kv-6K for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 01:44:47 -0500 Received: from qproxy5-pub.mail.unifiedlayer.com ([69.89.21.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pIl8m-0001JH-7T for emacs-orgmode@gnu.org; Fri, 20 Jan 2023 01:44:46 -0500 Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 414EA80317F3 for ; Fri, 20 Jan 2023 06:44:30 +0000 (UTC) Received: from cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway5.mail.pro1.eigbox.com (Postfix) with ESMTP id D41F1100563A1 for ; Fri, 20 Jan 2023 06:43:29 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id Il7Zpe1gZJceRIl7ZphMHh; Fri, 20 Jan 2023 06:43:29 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=Or6Kdwzt c=1 sm=1 tr=0 ts=63ca3811 a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=DPR-AOO6AYYA:10:endurance_base64_authed_username_1 a=A2tt7buDTgEA:10:from_fastflux_domain1 a=pGLkceISAAAA:8 a=o9zw6IYYAAAA:8 a=W1xgHzpuOX-WYgQE8w0A:9 a=d_VElMKDodcA:10:uccc_2email_address a=BIPpIoh2KZEA:10:uccc_2email_address a=-FEs8UIgK8oA:10:nop_fastflux_domain_1 a=A9pLXl7zLAuIpCaAaqdO:22 a=BtxB1_lq3pBo68oZtZ_9:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tsdye.online; s=default; h=Content-Type:MIME-Version:Message-ID:In-reply-to :Date:Subject:Cc:To:From:References:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SihH34zVcpS6/r+I3t+nYdAYEwG/KeD5Nch2u1Vk2os=; b=uuF98TzmdTis+KhdpQKLG0WNhG rE7OHrkQTFVil3FtA/YQGD/4jTD2FcNXuugX2rC82YGXd867Mj++NbBq/WI0TyvXx1xYfdJU93uu1 NnAzuR3nH1dLSf94qY2SEjL3uwfVQegDl+6hzExD8H5CvKDTFz5WmabGXkS/zJWNAuAXOOf/VVXza zYOBB5Cw2A7Y+yyRyHrkGOuJ61OZvnEgW5UMXeUgBP2f50YBE+JmRzBMTbsI5CBjuTZndO08VbNxq nhDno4ruq/G59boT5bYjX/1eMTjdBUB+i5FwQ7puwc0iFYELXF1tbTr9U1wIcq979WUYyJNYSHX9n QbbLY8ZA==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:54326 helo=poto-foou.tsdye.online) by box2035.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pIl7Z-002vuO-0o; Thu, 19 Jan 2023 23:43:29 -0700 References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87mt6e86sr.fsf@tsdye.online> <63c9d976.620a0220.a7d40.113b@mx.google.com> <87tu0mjb24.fsf@tsdye.online> <63ca1283.170a0220.5bc81.0fdd@mx.google.com> User-agent: mu4e 1.6.10; emacs 27.1 From: "Thomas S. Dye" To: Tim Cross Cc: "Thomas S. Dye" , Jean Louis , 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 Date: Thu, 19 Jan 2023 20:14:44 -1000 In-reply-to: <63ca1283.170a0220.5bc81.0fdd@mx.google.com> Message-ID: <87pmb9k8oi.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box2035.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tsdye.online X-BWhitelist: no X-Source-IP: 50.113.33.148 X-Source-L: No X-Exim-ID: 1pIl7Z-002vuO-0o X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-50-113-33-148.hawaii.res.rr.com (poto-foou.tsdye.online) [50.113.33.148]:54326 X-Source-Auth: tsd@tsdye.online X-Email-Count: 6 X-Source-Cap: dHNkeWVvbmw7dHNkeWVvbmw7Ym94MjAzNS5ibHVlaG9zdC5jb20= X-Local-Domain: yes Received-SPF: pass client-ip=69.89.21.30; envelope-from=tsd@tsdye.online; helo=qproxy5-pub.mail.unifiedlayer.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674197143; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=SihH34zVcpS6/r+I3t+nYdAYEwG/KeD5Nch2u1Vk2os=; b=ewEpsv7zEpB9d02exWrUKWeCsK81RU6qBp2aEc04+Fh4B7XQ9FxUwEPUCK7XOdgzfxH3+c MWi6RI42LyA1FWzDdl7ALVxyWE5S547gcVjqAt3CnzmSmYjkJwyBKLnga/TzfIU4ljfeNq CXQgXRqAzgsWkCAJ5IBjY9NXoAFr0BCGPeEkU9SdwiIS/56zk0MDZxl/hZYuxXDetzZ0DA 2qwipYsjpckCQgW69/wKpzWVw/n0Nr56IuTIgYtiLmCmfZq3zChe2RoxXR0/wpVbC80MPc s1KXEthSQ7JT4AfCIXuiyWL5QjglNjMgoPa11NfsvQtUbLQWvmXsJdA6j843fA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=uuF98Tzm; dmarc=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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674197143; a=rsa-sha256; cv=none; b=r4S4LxswHQbsOQGh/9khP9QRGOt0sa0J8sYZ90adudL1hns5EyRWMXTXlr1cCoZEC5zSsc GyhZHYwL9d8vVFUC6Jl9pK/y/MSVE16neeJDmzcqTqIgaT4tW4CCCVyhOgZEgAXTeEalSX q7pRHyNZTMYedc+z9ZNPhH0dY0OhMw+LGBr081msqLTuwismAGyPAUOguzn8RqTnwB88GO x3LV0odh6en9HxEaO7P+kTSrXO04dClQp1vgEuBZitbXyMUwZ7KxqIlQ9VXqXhUXf0Tl9W RVRKdcnqqflAKKtmrFFhO4+lvkMdap1aVDz96WeMrcWdovTMpRMsL3Or/BRmOg== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 2.59 X-Spam-Score: 2.59 X-Migadu-Queue-Id: 9DBB23E9D2 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=uuF98Tzm; dmarc=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" X-TUID: oKfjlUDCRiRU Aloha Tim, Tim Cross writes: > "Thomas S. Dye" writes: > >> Aloha Tim, >> >> Tim Cross writes: >> >>> "Thomas S. Dye" writes: >>> >>>> Aloha Tim, >>>> >>>>> UTC is a time zone - just one where offset is +0000 >>>> >>>> UTC is absolute time. It lacks the spatial component that >>>> defines a time zone. >>>> >>> >>> Really? I would have thought the prime meridian was the >>> spacial >>> component for UTC? I thought the full long time zone name was >>> Etc/UTC >>> and UTC as the abbreviation. >>> >>> Regardless, in all the libraries I've used, you can use >>> Etc/UTC or UTC >>> in exactly the same way you would use something like >>> Australia/Sydney or >>> AEST. So perhaps, from a pedantic standpoint, it is not a time >>> zone, but >>> for all intent and purpose in this discussion, I feel that >>> point is >>> irrelevant. >> >> Agreed. It does seem irrelevant for time zone libraries. >> >> Nevertheless, from the Org perspective it might not be. An >> occurrence, which marks >> changes in the nature or relations of things at a time, >> requires absolute time. Meetings, >> which involve a change in relation among participants, are >> occurrences. IMO, this >> indicates Org should give occurrences a UTC timestamp, then >> translate that for each of the >> participants using their local time zone. The insane interval >> problems that Ihor brought >> up are moot in absolute time. A single timestamp serves a >> meeting regardless of whether >> the participants are all in one time zone or spread around the >> globe. >> >> An occurrence contrasts with an event, which is tied to the >> user's space/time. Time here >> is relative to the user. IMO, this means that Org should give >> events a timestamp without >> reference to either absolute time or a particular time zone, >> like the one it uses now. >> > > Just checking if I understand. I think we are coming from the > same > position and with the same conclusion. > Thanks! > In the situation where the meeting involves people from > different time > zones, the time of the meeting as reported by org needs to be > adjusted > after a daylight savings transition so that the time maintains > the same > relative to UTC. i.e. meeting time reported in local time goes > forward/backward 1 hour depending on the daylight savings > transition > (in/out). I guess this is what you call an occurrence? > > When all participants in a meeting are in the same time zone, > you do not > want the time changed as the result of the daylight savings > transition. > This is what you call an event? Every meeting is an occurrence because it involves changes in relations of things at time; in this case meeting participants relate to one another via Jitsi, regardless of whether they are all in one time zone or spread over the globe. An event's time is relative to the user's location, or space/time. So, the example I gave earlier "Brush teeth before bed" set to 10:00 PM, which works whether I am home in Honolulu or enjoying the hustle and bustle of Manhattan, is a simple event. It happens at that time in the timezone I happen to inhabit at the moment, because I intend to go to sleep shortly after 10:00 PM regardless of where I am. > > So, using your terminology, what we now need is convenience > functions > for setting an occurrence timestamp and an event timestamp. I'm > not sure > if occurrence/event are the best terms, but I cannot think of > better > ones. Just slightly concerned people will have trouble grasping > the > difference and undersanding why some meetings are an occurrence > while > others are an event. FOr the user, they are just meetings. Yes, both meetings are occurrences. I agree that the terms take some getting used to. I got them from Frank Ramsey, who seemed to be happy with event, but not so happy with occurrence. The difference is this: Will the happening being scheduled involve other people, who will share the Org timestamp, or will it take place at the same absolute time, regardless of where you are when it happens? If so, then the timestamp should be stored as UTC (it is an occurrence that requires absolute time). Or, is it something you want to do at a time, regardless of where you are. If so, then the usual Org timestamp without UTC is what should be stored (it is an event that requires time local to the user). In the case of a meeting, where the one who calls the meeting sends an Org file with a meeting agenda and a UTC timestamp to each of the participants, Org will translate the UTC timestamp into local time for each participant. Similarly, when you are traveling, Org will translate the UTC timestamp to the timezone you happen to inhabit. Here, I'm assuming that the timezone machinery is capable of determining local time relative to UTC. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye