From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yN8sITvdzGOejAAAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 07:52:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8JEqITvdzGMDdgAA9RJhRA (envelope-from ) for ; Sun, 22 Jan 2023 07:52: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 65ACDD414 for ; Sun, 22 Jan 2023 07:52:42 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJUCu-0001GC-DO; Sun, 22 Jan 2023 01:52:00 -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 1pJUCs-0001G1-AE for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 01:51:58 -0500 Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55] helo=progateway7-pub.mail.pro1.eigbox.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJUCn-0002qk-Lh for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 01:51:58 -0500 Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway7.mail.pro1.eigbox.com (Postfix) with ESMTP id 2A19A10048180 for ; Sun, 22 Jan 2023 06:51:48 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id JUCfpxOsQNX2aJUCfpkiYt; Sun, 22 Jan 2023 06:51:48 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NMAQR22g c=1 sm=1 tr=0 ts=63ccdd04 a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=TP2bQshwf_QVURmJ:21 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=MkL9Z6V2eBCr1k_hOsMA:9 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-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=0zrE25tL3R4bgDRCULZ6wBbEiCWNVO/t/5D5d9AewNM=; b=v6omauBJcGmhoqih3llcPV+fEV c18dETlVaTd2sGR5iEEbbvBBxFeHlq8oYYoAb1SyyOcn6k+k+B2wcSCLVmjyGPu26FDFEhbSVz45b +tBAlgUVeZIHJpdT5CvBvGF9Qr2/2jHXy4LpvARzGv+AJet0IKCBqXbR6jcuDjaqFNMeubZbBqqRN +6zRH72EZampF9TqpFsxFY9ebgfwx+XbYox2WnEw54CJOBuQbh7WM/HrZxTOjz1Hr0beSr+7tGRnG Sz569/PFs3uxr+h6J2RchQGnGBT1b7x+dfZNuJ9m5PF86CwaTzElg/HCgh6j4cpOWRe/051nuoqgT YJxef+aA==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:40818 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 1pJUCf-001Jkd-Bx; Sat, 21 Jan 2023 23:51:45 -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> <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> 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: Sat, 21 Jan 2023 20:17:14 -1000 In-reply-to: Message-ID: <87r0vnhxj6.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: 1pJUCf-001Jkd-Bx 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]:40818 X-Source-Auth: tsd@tsdye.online X-Email-Count: 2 X-Source-Cap: dHNkeWVvbmw7dHNkeWVvbmw7Ym94MjAzNS5ibHVlaG9zdC5jb20= X-Local-Domain: yes Received-SPF: pass client-ip=67.222.38.55; envelope-from=tsd@tsdye.online; helo=progateway7-pub.mail.pro1.eigbox.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.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=1674370363; a=rsa-sha256; cv=none; b=YtvAM8Tkq8GgOZclNaSEW+8Ff2gggKmg6xvoSkmu8ljRu7GbqDt/tXbFgzH4sBwR3PlFZA IGFknSOQbKBfu3tOd5hTqU+sHBLYv23OvOiiNRKxpb63vqXgCxx2m5KNwBlooDtCcWEKHc qTahNcq6NFUp9WCjKfkCu2AIQTK8fr6oTgIM5OiwCWAP2KlohG9vO1eTJt77x9FeKr2/Fi FzEB+S+q7H8X4Q0U1h+prZQ6YjfLWeQauriFJnF3V12EW+7cgj7FyfniTsxAXhQfA8weGh jzZZ4lfceq/bOiu99Qnst5G4qic2TCfnLGoXWAIvBFcTc/mqugNCh8NiHA+Zkg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=v6omauBJ; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674370363; 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=0zrE25tL3R4bgDRCULZ6wBbEiCWNVO/t/5D5d9AewNM=; b=UWqXh5TDGcEUhm7zcQ+eH4VUaprR678MopEsw+flPa5yQt19gAaruOAAHOIInWeOuJi1HN l9Wc55Q/rEVYDD3hhmovX0dEL+Ayqw7g1Pj5s/tR8KVVxiaswwWcTaNi+YVJYpPwm+8oX7 lzc2WBKkRDKKUFfE+k958bAijLT3RhDmRrOtQzpPn/Yifc1mpT63shRGcrnUFJ3cH1huR2 7Ygzx71dG0ncMukcFLAmozc31jynRnN+86xQtXuUHXSyWpYLDEvLtHVWjQb3mfrJhSQXeL VAZdP2xTFaQWf5kEcTopfVAmsBexvl8siw4UMzI5ZITBXpCEskz5tbKhyeKVCw== X-Spam-Score: 1.81 X-Migadu-Queue-Id: 65ACDD414 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=v6omauBJ; 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-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: 1.81 X-TUID: H0qq06BgLMCD Aloha Max, Max Nikulin writes: > Let's consider the following timestamp > > [2023-01-22 Sun 08:29@+1100] > > "@" is unimportant here, I take it from Ihor's examples. This > timestamp is from > the "Date:" header of your message. It is not UTC, but in my > opinion it is > equally precise (disregarding seconds) to a UTC timestamp. > > Would you prefer to have timestamps in your files in such form > or as > > [2023-01-21 Sat 21:29Z] ([2023-01-21 Sat 21:29@UTC], [2023-01-21 > Sat > 21:29@+00:00], etc)? > > Maybe [@1674336588] (seconds since epoch)? > > I consider storage format as a part of Org UI, so I believe that > [2023-01-22 Sun > 08:29@+1100] with offset of the usual time zone is more > convenient than > [2023-01-21 Sat 21:29@+0000]. Overlays may present your local > time in both > cases, but raw value with usual offset is easier to comprehend. > > When a file is shared by a group of people spread across the > globe, they are > free to use UTC or another fixed timezone or do not care at all > concerning > particular offset, it just should present. UTC is not a timezone. It is absolute time. > Postgres has a reason to insist on UTC since timestamps are > stored in binary > format as microseconds since epoch. It is important for > performance and there is > no room to specify offset. Org has to parse timestamps from > strings anyway, so > it is better to use format more convenient for humans. Agreed. > A side note. In my opinion, *by default* timestamps should be > created in local > time with no offset or timezone. There are should be some > preferences to enable > absolute timestamps and a function to fix offsets or timezone > identifiers for > existing timestamp when the user realizes that they become > necessary (e.g. > before a trip). I don't think there should be a default. If I'm correct that occurrences, events relative to user, and events not relative to user exhaustively classify the possibilities, then Org should insist that timestamps conform to one of these three possibilities. If the classification is complete, then there is no need for a catch-all default. > So I do not see any advantages of UTC in comparison to time > offset specific to > particular time zone, usually user's local one. My vote is > [2023-01-22 Sun > 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course, only > in cases when > identifiers like Australia/Sydney do not matter) with a > configuration option > with timezone used fix offsets in stored timestamps. The disadvantage of time offset specific to a particular timezone is that the timezone offset wrt UTC can change arbitrarily. This is a potential problem if the arbitrary change takes place between the creation of the timestamp and the happening it identifies. In contrast, UTC is guaranteed not to change. It is not a timezone, it is absolute time, a pure continuum. It is a requirement of occurrences. I'm not sure offset is necessary for events, given that offset can change arbitrarily. WDYT? It seems to me that once an event has been tied to a particular time in a particular time zone that Org's job is to take into account changes to that timezone, such as DST and arbitrary legislation. These changes in the event's timezone need to be propagated through the schedule for each user, so it is possible to synchronize local timestamps around the globe. All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye