From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 sGUjJswozWNYNgEAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 13:15:08 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id MMc4JcwozWMEBgAAG6o9tA (envelope-from ) for ; Sun, 22 Jan 2023 13:15:08 +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 3215214658 for ; Sun, 22 Jan 2023 13:15:07 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJZEn-0007dI-3G; Sun, 22 Jan 2023 07:14:17 -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 1pJZEl-0007d4-Og for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 07:14:15 -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 1pJZEk-0001OZ-5u for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 07:14:15 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pJZEh-0008Ui-Tu for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 13:14:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 22 Jan 2023 19:14:06 +0700 Message-ID: References: <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> <87h6wljhce.fsf@tsdye.online> <87cz79j5gu.fsf@tsdye.online> <63cb3036.170a0220.3ea60.3a93@mx.google.com> <878rhwk8jk.fsf@tsdye.online> <874jsjkgpf.fsf@tsdye.online> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: <874jsjkgpf.fsf@tsdye.online> 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674389707; 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=Ybfi/XwUyxRw8GeQZ6BV25i2Gg32lmT5cleSdvJhPjw=; b=qw6UQwLOsdgbIfvnnh7Mhg4PyfSO7D9kP5yJLPktRsTAluT9hgp5BKA4RzNzd6uFfSWEQh /1E5cigUgqhuikLiLmG9eM79jVAtiSiSbrIzTQ+p3t8ztCyRSCa4kiWl/MmwcAU/cKRerv NtNuqtxThVKUSCQEuqR1VZp09Y04Q/2NT+Uo1RdkF8TzmaiEPqCZX12SB6pSKsmh8TJreE HKn1+et3+YQzTK6XPVE2Pk//68gFdi657FV2RA6HLYZ3C/xi4wsiDW9lP76YoNidC3LzcS LbvFAWQs4auEeF2gthbB9EP0n6QFJA/fDQ+K0JZ5F7o+9J5ZgqIwz30kABF92g== 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-Seal: i=1; s=key1; d=yhetil.org; t=1674389707; a=rsa-sha256; cv=none; b=AyD6PwN0TOp+zwvmN83fWk68j5EN3MHAlBviyJG5m0VcFfXSmJB8rdNnk9M3Vg5/0TJr51 i91gTOpVaENPmqCPjQg1ID5Eklv5oy/59jwuNX+q1+esMVaL6sdcudBclKTfjYWCc+cEmI kXtp5Eq/TcsYxuP2NC62QexvIbK7LxdKyNWpM06zh6JA2+EvAqQV1jKf25DpL4I+LMibE0 Xas/pyPpt7dE3E6JjNPoCPqiRX+el6REz00hIZL2Bf2iuJA7prXTOZ+Wpu31CRKMaBCNpu Z3l01EWb3Ng1mManNuSCIr1SAps6G3g+W/82McIpILS1C+eeDzTtXUB9PnN1Yw== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 4.11 X-Spam-Score: 4.11 X-Migadu-Queue-Id: 3215214658 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-TUID: II3APKKf/V+G On 21/01/2023 22:55, Thomas S. Dye wrote: > Aloha Max, > > Max Nikulin writes: > >> On 21/01/2023 07:37, Thomas S. Dye wrote: >>>>> 1) Occurrence, where the timestamp includes UTC; >>>>> 2) Event relative to user, where the timestamp does not include UTC >>>>> or a >>>>> time zone; and 3) >>>>> Event not relative to user, where the timestamp includes the >>>>> relevant time >>>>> zone. > > I'm curious to find out how the distinction between past and future > makes a difference. For timestamps in the past "absolute" time is almost always known, so beside timezone identifiers like Australia/Sydney it is possible to use UTC or fixed offset 2023-01-21 Sat 05:55:54 -1000. If a timestamp in future is bound to specific timezone then its identifier must be used since the government may change time offset. Of course there are cases when UTC or timestamps with fixed offsets are used as well: e.g. Lunar eclipse or participants with multiple locations are expected. So it is "feature" of some timestamps in future that attempt to store them in UTC may lead to their invalidation later. >> As to format for storage timestamps in Org files, particular >> timestamps may have >> or not explicitly specified timezones, but it is unrelated to these 3 >> cases. > > I'm curious to learn the classification unrelated to these three cases > used to determine when to store UTC and timezone. ... >> From my point of view these, 3 cases might be relevant to date-time >> picker UI, >> but not for storage format. While parsing, interpretation of each >> timestamp >> without explicit timezone depends on preferences chosen at higher scope. > > I'm curious what these preferences are, or might be. Is the following timestamp is in user local timezone or in UTC? <2023-02-01 Wed 15:00> If features like the following is implemented then it will not be in local time zone: - file-local #+TIMEZONE: UTC or #+TIMEZONE: Australia/Sydney - subtree-local * H1 :PROPERTIES: :TIMEZONE: Australia/Sydney :END: So looking at such timestamp it would be hard to choose particular case from the set you proposed. Of course it leads to tricky cases when some timestamp is copied to a scope with another time zone. It requires some yank handler and text properties. When timezone is added to a subtree, perhaps, all timestamps inside may need to be changed from implicit timezone. For storage format I would use another types - explicit/implicit time zone - Specific timezone/fixed offset. UTC and Etc/GMT-11 zones are identical to +0000 and +1100 offsets accordingly. For UI it is better to choose some terms to make the manual and UI dialogues more clear. I am not a native English speaker and terms "event", "occurrence" sounds confusing for me. E.g. a conference is an event. A regular meeting (even when scheduled in another time zone) or "brush teeth" are more close to occurrence. As soon as you have to split "event" category into 2 parts perhaps it is better to pick 3 different names. I may ask for fourth that is absolute, but not UTC, but I would prefer to not insist on namely UTC and use fixed offset instead. For UI it is meaningful to name - default time zone for this scope (with a hint if it is currently system-wide, file-local, or specific to subtree), so no explicit timezone will be set. - absolute (UTC or fixed offset) preferred for global event - bound to location (e.g. Australia/Sydney) - ad-hoc timezone that follows user in their trips (close to Ramsey's "occurrence"). The problem is to push users to timezone identifiers for future timestamps associated with some location. Offsets must be discouraged this case, but encouraged for on-line meetings. For past timestamps particular choice is less important. That is why I separated future/past timestamps. > Agreed.  The boss needs to inform you what her local time will be for > the meeting by sending you a timestamp with a time zone. Ideally, Org > would know how to associate the timestamp with a recurring item stored > locally. Unsure it it may be implemented reliably. > Nowadays, I am frequently asked by applications to give permission for > using my location.  When I give it, the application reports back with my > local postal code, etc.  I'm assuming Org can use location to determine > my current timezone. libc has a concept of timezone. I think, it should be the primary source. It is initialized on application startup (roughly) from system-wide settings, may be overridden by TZ environment and changed later by setting another value of TZ. The problem is that identifier like "Australia/Sydney" is considered implementation specific and is not directly accessible from the code, it is sealed inside the library. Another issue is that I do not know if Emacs is able to receive notifications on change of system-wide timezone. Web-application may request time zone settings from the browser: new Intl.DateTimeFormat().resolvedOptions().timeZone Android devices may have outdated and incomplete zoneinfo database. This case either computations should be performed on the server or tzdata copy should be bundled into the app. Client-server application may use resources maintained on servers, emacs must be able to run off-line and enough user will be unhappy noticed some outgoing queries. Ubuntu installer or e.g. Google relies on GeoIP databases. Geodata for timezones is available, but laptops or desktops mostly do not have GPS receivers. IP behind NAT is not useful to determine location. It is possible to make GeoIP database (quality of ones available for free are not high) and map of timezones, but I do not think it is reasonable. I suppose, system timezone would be enough for Org. Third party packages might implement another way.