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 fyt2GP7OzGP+lwAAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 06:51:58 +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 WBzeFv7OzGM5oAAAG6o9tA (envelope-from ) for ; Sun, 22 Jan 2023 06:51:58 +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 D7A7D266D4 for ; Sun, 22 Jan 2023 06:51:56 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJTFp-0007o1-4q; Sun, 22 Jan 2023 00:50:57 -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 1pJTFl-0007nj-DG for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 00:50:53 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJTFj-0001oy-V7 for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 00:50:53 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pJTFh-0007wW-Pz for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 06:50:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) Date: Sun, 22 Jan 2023 12:50:43 +0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <63cc5983.620a0220.a7d40.68f6@mx.google.com> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.092, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=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=1674366717; a=rsa-sha256; cv=none; b=U48L/rtrHclH/aqOk6rUYFu4q1zyeKoKHlOfnlbQmGR06vRFHTbtNY8rUbQRZHylZU09g0 SdAkAaLQ2RT8xTkWYk60Pz7sh2C19Mv1sJOXDAIk6KTxNSdu9wi8wrnjTGo0YlDqFNy0Kt vx8viGgft0wFkS/l3tQw96OriwI6jTNUY63YGxN0e+i7lE2GbIbJvkIZKjrmu21EBeHOSW u1RIRRnGp3CNmysC92UiWZokV0XEyLfBr+miHfW7prKH0nG2GGK/T1OVQ65k7kPTGRPAFq XeZp+gK5DowL3+8d1YODzmYew0RB1sRhgwx6S08dNm8fP5AlO6LQVL6qHccmsw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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=1674366717; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=1s6UUiXQotrogzQE4t9SdnqpBGWs0Ley8HCnqzrggY8=; b=UOTLkuKpQRs2lHckTKewV7IJkh38VAYqjpfHkNOyAeSyNYLVFxhl01EGZELFxoRXolJvc7 yZVzG+KjpO5A5SnsbhCaonj3JESFTNxBce4cRi8lk/Vrsc736z8UYFfNMmVJO1qOP/Vcvd bzRB731GhirjqC9U8XJxa6H6tHb/aKkjuRHYXpVN6vcGIOstYjyt8v4HIp0eRJpHtMjrpq veU2ZPIrkoLSYnkZ5TgpysN6khP5MfRTrH8v5PmLIgoWtzUODxeUUhzsY5W7XO9N28HzW+ YafYG6tYO+lelU39vNjLCzfkowVP63iNZnJjBa+IjtXCe1ghjDIvWbGkUkOSjw== X-Spam-Score: 3.31 X-Migadu-Queue-Id: D7A7D266D4 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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: 3.31 X-TUID: 8btZDctd45BT On 22/01/2023 04:29, Tim Cross wrote: > Max Nikulin writes: >> - UTC is a recommendation for planning when participants are scattered over multiple >> timezones. >> - You admit that some timestamps in your files may be specified as time zone identifier + >> local time relative to this zone. >> - In both cases you may configure overlays to use local timezone or another one whatever >> you currently find convenient. >> - Time chooser offers several time zone options. > > That seems to be in-line with what I was arguing, so yes, would agree. Great. At this stage my goal is to convince people that local time and UTC for future timestamps are not enough for real life use cases. Arbitrary timezone may be crucial to arrive at proper time despite it matters in rare cases. My concern is mostly storage format, timestamp syntax in Org files. On 21/01/2023 06:38, Tim Cross wrote: >>> I would also argue UTC is good for 'traditional' timestamps which record >>> a specific point in time and for situations where you want accurate >>> calculations of time durations. 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. 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. 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). 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.