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 +DmJCHu90mPQpAAAbAwnHQ (envelope-from ) for ; Thu, 26 Jan 2023 18:50:51 +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 6KGGCHu90mMlDgEA9RJhRA (envelope-from ) for ; Thu, 26 Jan 2023 18:50:51 +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 9A545380B1 for ; Thu, 26 Jan 2023 18:50:50 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pL6NP-0003WE-Uj; Thu, 26 Jan 2023 12:49:31 -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 1pL6NM-0003Vx-4i for emacs-orgmode@gnu.org; Thu, 26 Jan 2023 12:49:29 -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 1pL6NI-0008P6-Lz for emacs-orgmode@gnu.org; Thu, 26 Jan 2023 12:49:27 -0500 Received: from outbound-ss-761.bluehost.com (outbound-ss-761.bluehost.com [74.220.211.250]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 2922C802DC62 for ; Thu, 26 Jan 2023 17:49:10 +0000 (UTC) Received: from cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway8.mail.pro1.eigbox.com (Postfix) with ESMTP id 7D91310046D2C for ; Thu, 26 Jan 2023 17:47:06 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id L6L4pzqOTiJ4bL6L4p3CsK; Thu, 26 Jan 2023 17:47:06 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NNEQR22g c=1 sm=1 tr=0 ts=63d2bc9a a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=TP2bQshwf_QVURmJ:21 a=IkcTkHD0fZMA:10:nop_charset_1 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=iN7WMU6LiRPm1qJY528A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-FEs8UIgK8oA:10:nop_fastflux_domain_1 a=EVVv6iHyYxc8UI9aA31H: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-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To:From:References:Sender :Reply-To: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=iwGDb3VGt4lmFx1r3JCyuiIkbCpuV3zDfoDaQXxjayg=; b=cgwlH3TbPvCUK3yxUOKJDhxsB3 RyMH+9Woxd0tbRXaJoyxsS6X8vsvX/G91AsiMhkddiRPjqKIliddW94cXhOIAk6/fKzEdvzUCWMJy CLrBsMeE+E7greec5EZ4e9+YkHxpfdRflpAOZWCVzoM3hE3pywW0yK4EwycX75LmuRpL5cl3583dM 47f2tlw5o2YLG3ms9GpMA/g2/XLM7tf1wC7jciO+lPLchBnVloOan+YtFEFFvZZQqTuqRcnwgLF/C zPnKi08FXgKfmF4Z2rYSqkMrOTiSbtqYgKkD3tqeCqIe0W6TpTmws9Jo1BP+zFFGfItAC8btMn5fJ ZnKWKlMQ==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:51076 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 1pL6L3-001rhy-RK; Thu, 26 Jan 2023 10:47:06 -0700 References: <87lelxk87a.fsf@tsdye.online> <63ca5101.630a0220.b2298.3363@mx.google.com> <63cb2d0b.630a0220.f919a.6174@mx.google.com> <63cc5983.620a0220.a7d40.68f6@mx.google.com> <87r0vnhxj6.fsf@tsdye.online> <87ilgyiid8.fsf@tsdye.online> <87edrli4sr.fsf@tsdye.online> User-agent: mu4e 1.6.10; emacs 27.1 From: "Thomas S. Dye" To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) Date: Thu, 26 Jan 2023 06:31:47 -1000 In-reply-to: Message-ID: <87tu0dfasn.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: 1pL6L3-001rhy-RK 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]:51076 X-Source-Auth: tsd@tsdye.online X-Email-Count: 2 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.498, 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-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674755451; a=rsa-sha256; cv=none; b=Qrkd+yH83kYrKpjKhQ6ZVPK7R/oc85M5g+cDvg4XxIqfOdLoil1fl91NR1cB2+ubiuiO7u yODcbvE9OgELUaRzzwuY42DvHy++pMGB9rCzie8b9DcpE/zTDnqkHQYJKpW0Z6usFyv5OI cnEA5wR4+AgxYty761bGF8jHRbHs7frDQdPvCQseZBjlNTttQYCY/hy/KaIVXLVn5zIxKf 1UZhfhjwqyfrHcXKnnegWIYqiV8nRrNNbUl3DExi9IPQJsyJ4Pk0ydfaeD1K+hlpJ3pNFE UzX/LkcDKlSmH9HqJ9+2uQnUw267s62Ni2RNUW8PoddmTgbxY2UEXC7oTbffNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674755451; 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:dkim-signature; bh=iwGDb3VGt4lmFx1r3JCyuiIkbCpuV3zDfoDaQXxjayg=; b=d3uMb8T519LZd4n2xdXSK+wzGfLvGBGIG1NbSzStJ41Y4Ty7BaTp+A0jAlSECary7ySl/w cbMuXT9FZ+HBIQooJGjoSJ/1rXZgHw7NpvnjOhDx/gew7GZ9ets7+47vUJrzdQiRqjIjvB aIiNpBWtBLiE1YV4XQaJn57Ime5i+HnpHWrG3TV/Rm/bcT4HhRos0tiYqUOUqPR45HMy5t rAcPKH36eBhhc0POy8Y75zpyE1AJcr4cmjfmn7x0ySNRGkMbtE0JEme7OeTHgZJUgN6MGW zvXcMypGwbxbZi7m4wo87kvv5QvWVv5EhFlnsdE2j7My/SSbAfrtsKV6tXC9gw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=cgwlH3Tb; 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: scn0.migadu.com X-Migadu-Spam-Score: 0.33 X-Spam-Score: 0.33 X-Migadu-Queue-Id: 9A545380B1 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=cgwlH3Tb; 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-TUID: hmP0LM4aGz/c Aloha Max, Max Nikulin writes: > On 23/01/2023 23:04, Thomas S. Dye wrote: >> * Kinds of event >> - No-host event :: An event that takes place at an absolute=20 >> time. Participants >> must know their local timezone offset from UTC. Example=20 >> [2023-01-23 >> 06:00@UTC]. >> - Situated event :: An event that takes place at a time local=20 >> to the event >> site.=C2=A0 Participants must know their local timezone offset from=20 >> UTC and the >> event site timezone offset from UTC at the time of the event.=20 >> Example >> [2023-01-22 Sun 08:29@Australia/Sydney]. >> - [Itinerant | Traveling | Mobile] event :: An event that takes=20 >> place at a >> time local to the event site, which might change after the=20 >> event has been >> scheduled.=C2=A0 Participants must know their local timezone offset=20 >> from UTC and >> the event site timezone offset from UTC at the time of the=20 >> event.=C2=A0 Examples >> might be a regular staff meeting that takes place at 9:00 AM=20 >> wherever the boss >> happens to be, or a proposal to meet with a traveler when it is=20 >> noon on Sunday >> for the traveler. Example [2023-01-23 06:00].=C2=A0 In this case=20 >> timezone is set >> according to user timezone preference in scope. > > Thomas, I mostly agree with the set of event kinds your=20 > suggested. Perhaps names > should be justified to have precise and concise terms in UI.=20 > From my point of > view their value is association with appropriate storage format=20 > for particular > timestamp. > Agreed. Another idea for the mobile event is "variably situated=20 event". I don't doubt that better terms might be proposed. > An additional parameter (or sometimes first one to choose) is if=20 > explicit or > implicit time zone should be used in the file. In the latter=20 > case the same kinds > of events are possible, particular one is determined from a=20 > parent scope. User > should be just aware what is actual time zone if it is implicit=20 > one. I was trying to capture this in the timestamp, where an explicit=20 time zone is indicated and an implicit time zone is simply a date=20 and time. > > The following concept is aside from event kinds, but might (or=20 > might not) be > useful to present agenda, to schedule events, to implement the=20 > feature. Perhaps > a trip may be considered as an ad hoc timezone that follows=20 > offsets of time in > locations to visit. (Several such ad hoc time zones may allow to=20 > track schedule > of several people, but it may be too complex to use.) It may be=20 > considered close > to "mobile" event, but the purpose is not to ensure correct time=20 > of particular > event. It may facilitate presentation of timeline during the=20 > trip. An alternative would be to have headlines for each stop on the=20 trip, each of which has a #+TIMEZONE property. Under each=20 headline would be subheads for events, each with a timestamp for a=20 "mobile event". Org would let me toggle the times of these events=20 relative to my current location, the event location, and UTC. > > Perhaps it is more correct to talk about how events are=20 > scheduled, not of event > kinds. Consider Christmas and similar events. It is personal and=20 > local for each > user. If you share your .org file (with specified file-local=20 > time zone) with > other persons they celebrate accordingly to their local time. In=20 > addition they > may decide that it should be pleasant for you to receive a=20 > greeting close to > your local time. In the first case, "Open Christmas presents at 8:00 AM", the event=20 would be variably situated because I want to do this on the years=20 I celebrate at home and also the years when I celebrate with=20 friends and family in other parts of the world. A timestamp for a=20 variably situated event shares well--the recipient user needs to=20 ensure that the event is stored within user's local time zone=20 scope. In the second case, "Send Christmas greetings to Max when he opens=20 presents at 8:00 AM" would be an event situated at the place Max=20 is celebrating--it is separate from the first case. If I know=20 where Max will celebrate Christmas, then I could use a timestamp=20 for a situated event. Otherwise, I would use a timestamp for a=20 mobile event and make certain to ensure that the time zone scope=20 for the event tracks Max's whereabouts. > > It seems during discussion we use terms in slightly different=20 > meaning, so I will > try to clarify my point of view. > > I had a course on general relativity theory, so "absolute time"=20 > does make much > sense for me. UTC is just a widely accepted agreement. I was=20 > bound to Earth > rotation and accumulated some offset from more precise atomic=20 > clocks. UTC > however currently is easiest way to perform time related=20 > calculations. Yes, UTC is the sign we've widely agreed to interpret as absolute=20 time. A key property is that UTC is a continuum, absent the=20 potential discontinuities that characterize space/time units like=20 time zones. > My perception is still that UTC is one of timezones that may be=20 > used to specify > event time. It is a bit special since it is used as a reference=20 > for other time > zones, so it may be preferable for global events. If UTC=20 > considered as an > ordinary time zone then the whole set of time zones may be=20 > divided into 2 > classes: with fixed time offset (including UTC, Etc/GMT+3 that=20 > may be specified > as -03:00, etc) and with time zones associated to specific=20 > locations. Second > class is affected by DST, changes of offsets that may be source=20 > of uncertainty. > The role of UI is to help user to choose a timezone that is=20 > suited best for > particular event. For events in the future often it is necessary=20 > to use a=20 > location-based time zone, in other cases it is UTC or anyone=20 > with fixed offset. > When you recording current time, explicit offset may be better.=20 > I am still > unsure what is better to use: kinds of events or kinds of time=20 > zones. > Well, you know where I stand on this---UTC is not a time zone and=20 no good comes from confusing it with one. Nevertheless, the UI=20 issue need not require the user to grasp the distinction between=20 event and occurrence. My idea was to use "no host event" to refer=20 to an occurrence. To my mind, "no host" gets to the point of "not=20 associated with a particular region of space/time", so that=20 calling it an event, a fundamental space/time unit, is less likely=20 to cause confusion. > I agree that offset as a part of timestamp may be confusing, but=20 > I am afraid > that significant part of affected users are unaware of UTC as=20 > well. That is why > proper UI may be a challenging task. > The discussion around this point confuses me. One the one hand, a=20 timestamp for absolute time (UTC or offset from UTC) should be=20 stored in the format that minimizes computations that will=20 subsequently involve it. On the other hand, the user can toggle=20 or otherwise see (Ihor's eldoc solution) the timestamp in the=20 format that makes the most sense, so the readability of the=20 storage format is not really at issue. > Thomas, for me event kinds are less important than understanding=20 > that UTC > timestamps are not enough achieve properly working schedule.=20 > Currently you see > that timezones associated with locations in some cases must be=20 > used in stored > timestamps. Have you noticed that I missed anything significant=20 > in your > messages? No, I don't think you've missed anything significant. Thanks very=20 much for your patience during a discussion that was interesting=20 for me. I learned quite a bit from you and the other contributors=20 to the thread and look forward now to learning how Org mode=20 evolves to handle events and occurrences. Let me know if you have questions. All the best, Tom --=20 Thomas S. Dye https://tsdye.online/tsdye